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ABSTRACT 

This  thesis  describes  and  tests  a  system  for  Low  Cost  Graphics  (LO-CO-GRAF) 
which  enables  a  small  computer  to  generate  and  display  high  quality  cartographic  maps 
from  a  remote  mainframe  computer  database.  A  small  computer  must  emulate  a 
graphics  terminal  while  interfacing  with  a  mainframe  program  which  processes  the  nec- 
essary data.   This  solution  has  been  accomplished  through  four  smaller  tasks. 

The  tasks  include  communicating  with  the  source  system,  emulating  a  graphics  ter- 
minal, interfacing  with  a  map  generation  program,  and  producing  a  local  hardcopy  of 
the  generated  map.  All  software  and  hardware  required  for  these  component  parts,  in 
addition  to  the  use  of  scandard  methodologies,  were  selected  for  their  widespread  avail- 
ability at  Department  of  Defense  (DOD)  agencies. 

Research  was  conducted  using  the  Heath/Zenith  Z-120  as  the  small  microcomputer 
and  the  Tektronix  4010  graphics  terminal  was  chosen  to  model  and  emulate;  two  sepa- 
rate source  graphics  packages  were  used  to  generate  maps.  Concept  validation  involved 
the  use  of  DISSPLA,  the  primary  graphics  package  used  on  an  IBM  3033  mainframe 
computer  at  the  Naval  Postgraduate  School,  and  the  Briefing  Aid  System,  a  map  gen- 
eration program  maintained  on  the  VAX  mainframe  computer  at  University  of  Southern 
California's  Information  Systems  Institute,  which  was  accessed  and  employed  via  De- 
fense Data  Network  (DDN). 

Specific  "how-to"  instructions  were  developed  for  application  to  the  Heath/Zenith 
Z-100  series  microcomputer.  These  instructions,  which  are  provided  as  Appendices,  in- 
clude programs  which  cause  the  Z-100  microcomputer  to  emulate  a  Tektronix  4010 
graphics  terminal,  provide  microcomputer  to  mainframe  computer  communications  us- 
ing KERMIT,  present  interactive  DISSPLA  map  generation  programs,  and  explain  how 
to  access  the  Briefing  Aid  System  map  generation  program  via  the  DDN. 
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THESIS  DISCLAIMER 


A.  SOFTWARE 

The  reader  is  cautioned  that  computer  programs  developed  in  this  research  may  not 
have  been  exercised  for  all  cases  of  interest.  While  every  effort  has  been  made,  within  the 
time  available,  to  ensure  that  the  programs  are  free  of  computational  and  logic  errors, 
they  cannot  be  considered  validated.  Any  application  of  these  programs  without  addi- 
tional verification  is  at  the  risk  of  the  user. 

B.  TRADEMARKS 

The  following  trademarks  are  used  throughout  this  thesis: 

Chromatics  is  a  Trademark  of  Chromatic  Computer  Corporation. 

DISSPLA  is  a  Trademark  of  Integrated  Software  Systems  Corporation. 

DISSPOP  is  a  Trademark  of  Integrated  Software  Systems  Corporation. 

Epson  is  a  Trademark  of  the  Epson  Computer  Company. 

IBM   is  a  Registered  Trademark  of  International  Business  Machine  Corporation. 

KERMIT  is  a  Registered  Trademark  of  Jim  Henson's  Muppets. 

MS-DOS  is  a  Registered  Trademark  of  Micro  Soft  Corporation. 

Okidata  is  a  Trademark  of  the  Okidata  Corporation. 

Tektronix  is  a  Registered  Trademark  of  the  Tektronics  Corporation. 

VAX  is  a  Trademark  of  Digital  Equipment  Corporation. 

VM/CMS    is  a  Registered  Trademark  of  International  Business  Machine  Corpo- 
ration. 

VS  Fortran  is  a  Registered  Trademark  of  International  Business  Machine  Corpo- 
ration. 

Zenith  is  a  Registered  Trademark  of  Zenith  Data  Systems  Corporation. 
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I.  INTRODUCTION  AND  BACKGROUND 

Effective  Command  and  Control  (C2)  relies  heavily  on  accurate  maps  and  charts 
that  are  readily  obtainable  with  minimum  delay.  While  pure  command  post  exercises 
of  hypothetical  scenarios  may  not  be  adversely  affected  by  inaccurate,  incomplete,  or 
artificial  cartographic  products,  any  actual  movement  of  men  and/or  equipment  requires 
that  the  commander  and  his  staff  have  timely  access  to  comprehensive  and  up-to-date 
maps.  This  requirement  prevails  throughout  each  step  of  any  exercise,  planned  maneu- 
ver or  crisis  management  situation  [Ref.  1:  p.  3-80].  A  commander  who  ignores  his  map 
requirements  during  the  concept  phase  of  operations  is  sure  to  fail.  Maps  and  charts 
are  essential  tools  for  those  in  charge  of  staffing  and  planning.  General  George  S. 
Patton,  who  will  always  rank  as  one  of  the  Army's  and  our  nation's  greatest  warriors, 
stated  the  importance  of  maps  very  simply  in  his  biography. 

A  study  of  the  map  will  indicate  where  critical  situations  exist  or  are  apt  to  develop, 
and  so  indicate  where  the  commander  should  be  [Ref.  2]. 

Perhaps  the  need  for  maps  is  most  critical  in  the  execution  phase:  the  success  of  even  the 
simplest  operation  hinges  directly  on  the  reliability  and  availability  of  accurate  maps  and 
charts.  To  put  it  simply,  timely  access  to  maps  and  charts  is  an  indispensable  C2  tool 
and  must  be  available  at  all  levels  of  command  during  all  phases  of  the  C2  process  [Ref. 
1:  p.  3-82]. 

The  usual  procedure  for  obtaining  maps  in  the  Department  of  Defense  (DOD)  is  to 
request  them  from  the  Defense  Mapping  Agency  (DMA)  or  one  of  the  affiliated  military 
distributing  commands.  This  requires  intricate  preplanning  for  anticipated  future  needs, 
as  well  as  a  long  lead  time  of  anywhere  from  a  few  weeks  to  several  months  due  to  the 
logistics  involved  in  physically  locating,  obtaining,  and  delivering  the  desired  maps  and 
charts.  To  expedite  this  process,  the  DMA  has  digitized  most  critical  world  areas  so  that 
the  cartographic  information  can  be  transmitted  electronically.  This  innovation,  while 
an  important  first  step  in  providing  accurate  and  timely  map  data,  is  somewhat  limited 
in  its  present  configuration  because  only  specially  dedicated  computers  and  network 
systems  can  access  the  information.  However,  this  information  is  available  on  many 
mainframe  computers  and  accessible  through  resident  graphics  packages,  l  Indeed,  many 


1  For  example,  the  Naval  Postgraduate  School  (NPS)  uses  the  Display  Integrated  Software 


of  the  large  screen  displays  currently  used  in  C2  centers  for  contingency  planning  and 
for  the  World  Wide  Military  Command  ard  Control  System  (WWMCCS)  displays  are 
of  inferior  cartographic  resolution.  Most  importantly,  the  DISSPLA  software  allows 
anyone  operating  a  NPS  graphics  workstation  to  generate  the  exact  cartographic 
projection  desired.  The  significance  of  generating  detailed  cartographic  products  by 
DISSPLA,  is  that  most  organizations  also  have  a  similar,  unrealized  capability  to  have 
this  type  of  small  scale,  large  area  mapping  program,  which  can  provide  them  almost 
instantly  with  the  maps  and  charts  they  require. 

A.     GRAPHICS  IN  THE  MILITARY  ENVIRONMENT 

This  thesis  is  specifically  directed  towards  the  creation  of  maps  and  charts,  which 
usually  represent  the  highest  level  of  capability  available  in  graphics  packages.  The  dif- 
ficulty to  genera*'!  ~  aps  involves  translating  a  three-dimensional  data  set  generated  by 
the  curvature  of  the  earth  into  two-dimensional  projections  that  can  be  printed  as  maps. 
The  need  for  accurate  maps  and  charts  has  already  been  mentioned  in  general  but  the 
following  specific  applications  serve  to  better  illustrate  this  requirement. 
1.  Command  and  Control  (C2) 
a.     Pre-planned 

Maps  are  always  needed  when  forces  are  being  employed  or  deployed.  C2 
is  exercised2  via  Command,  Control,  and  Communications  (C3)  systems;  the  commander 
and  his  subordinates  must  be  "working  from  the  same  sheet  of  music".  The  exchange 
of  information  necessary  to  achieve  a  successful  mission  is  critical,  and  usually  very 
susceptible  to  error.  To  relay  his  C2  decisions,  the  commander  could  prepare  an  inter- 
active computer  menu  program^  which  could  be  made  available  to  other  commands, 
making  clear  the  decision.  The  maps  with  overlayed  or  imbedded  information  could  be 
either  electronically  transmitted  or  simply  made  accessible  to  others.  This  delicate  C3 
problem  is  resolved  with  a  C4  (add  "Computers"  to  C3)  solution.  Figure  1  illustrates  the 
dissemination  of  a  map  presentation  from  the  commander  and  his  staff  to  other  elements 


System  and  Plotting  Language  (DISSPLA)  graphics  software  program  which  contains  a  map  gen- 
eration option  called  World  Coast  Utilities.  Although  this  program  is  independent  of  the  DMA 
database,  and  therefore  does  not  reflect  the  continuous  DMA  updating  of  maps  and  charts,  it  can 
generate  high  resolution  products  that  are  amply  sufficient  for  the  strategic  and  operational/theater 
levels  of  military  planning  and  execution. 

2  C3  is  sometimes  referred  to  as  "the  reins  of  command",  that  is  the  commander's  ability  to 
maintain  control  of  the  situation. 

3  Similar  in  concept  to  the  program  provided  in  Appendix  A  in  that  different  options  or  bases 
for  decision  can  be  provided  electronically. 
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Figure  1.  Use  of  Digitized  Maps  in  Normal  Operations:  Distribution  of 
commander's  intentions,  EOOB,  admin/ log  information,  and  C3  proc- 
esses of  the  C2  functions  through  Local  Area  Networks  (LAN),  Defense 
Data  Network  (DDN),  or  telephone  quality  communications  lines. 


in  his  chain  of  command.  With  this  map  distribution  tool,  the  commander  can  provide 
timely  progress  reports  to  his  superiors,  advise  and  inform  adjacent  commanders  of  his 
intentions,  and  effect  swift,  unambiguous  C2  direction  to  subordinate  command  ech- 
elons. 

b.     Emergency  (contingency  (crisis  situations 

Similar  to  the  preplanned,  deliberate  scenarios,  a  commander's  effectiveness 
in  a  crisis  situation  can  also  benefit  from  a  C4  application  of  digitized  mapping.  Speed 
and  accuracy  of  information  transmission  is  Dossiblv  even  more  critical  during  an  emer- 


gency  or  crisis  because  decisions  are  being  made  and  forces  deployed  with  all  possible 
speed.  A  precise  display  of  forces  and  enemy  order  of  battle  from  his  superior's  com- 
puter could  prove  invaluable  to  the  on-scene  commander.  Additionally,  weather  and 
other  displays  could  be  made  instantly  available  to  him. 

Most  contingency  operations  usually  are  directed  from  a  major  command 
center.  The  personnel  handling  these  emergencies  are  usually  referred  to  as  a  Crisis 
Action  Team  (CAT)  or  a  Crisis  Management  Team  (CMT).  Their  composition  is  made 
up  of  operators  and  specialists  in  communications,  logistics,  intelligence,  and  other 
warfare  and  combat  support  occupations.  Figure  2  demonstrates  how  the  on-scene 
commander  and  the  CAT  or  CMT  can  access  tactical  maps  requiring  only  communi- 
cations to  some  remote  mainframe  computer.  Figure  2  also  demonstrates  another  ad- 
vantage of  digitized  maps:  the  graphic  link  between  the  on-scene  commander  and  the 
Crisis  Management  Team  which  reciprocally  would  provide  up  to  the  minute  decisions, 
results,  and  options. 

2.  War  gaming 

a.  Laboratory 

C3  is  usually  ignored  and  not  normally  a  determinant  in  laboratory 
wargaming  exercises.  However,  the  highly  specialized  systems  employed  to  generate 
terrain  and  similai  cartographic  displays  are  available  only  at  major  commands  and  in- 
stallations, limiting  their  usefulness  to  a  small,  elite  minority.  Using  digitized  maps, 
many  wargaming  systems  could  become  available  at  lower  level  commands.  With  the 
loss  of  dependence  on  highly  specialized  displays  and  systems,  more  inter-command  or 
distributed  wargaming  could  occur.  This  would  result  in  more  training  for  more  forces, 
with  obvious  benefits  accruing  therefrom. 

b.  Exercises 

Using  wargaming  in  conjunction  with  field  exercises  is  extremely  beneficial. 
Instead  of  being  limited  by  time  and  cost  constraints,  different  options  or  hard  to  field 
operations  can  be  conducted.  The  availability  of  digitized  mapping  programs  and  the 
increasing  presence  of  highly  accurate  and  current  DMA  data,  would  allow  more  play- 
ers, more  and  easier  access,  and  potentially  higher  quality  wargames  and  exercises. 
Again,  the  benefits  are  readily  apparent. 

3.  Other 

This  thesis  is  primarily  directed  towards  cartographic  products,  but  it  is  equally 
applicable  towards  other  graphics  products.     Strategic  analysts,  as  well  as  tactical 
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Figure  2.  Use  of  Digitized  Maps  in  Crisis  Situations:  Instant  accessibility  is  re- 
quired by  the  on-scene  commander  and  the  crisis  management/ action 
team. 


commanders,  monitor  the  activity  levels  of  numerous  indicators  [Ref.  3:  p.  86]  such  as 
enemy  order  of  battle,  troop  strength,  logistic  support,  levels  of  supplies,  casualty  rate, 
weather,  etcetera.  These  indicators  are  often  not  quantifiable  and  depend  on  some  other 
previous  analysis.  When  only  men  were  in  this  loop,  knowledge  of  the  general  situation 
and  of  the  other  analyst's  psyche  was  sufficient  to  judge  the  quality  of  a  decision.  The 
current  trend  in  technology  and  sensors  is  to  place  a  greater  reliance  on  the  use  of  Arti- 
ficial Intelligence  (AI),  specifically  Expert  Systems.  Versions  of  these  AI  systems  process 
raw  sensor  data,  perform  primary  estimations,  and  then  effect  dissemination  [Ref.  3:  p. 
35].   This  is  the  best  solution  when  dealing  with: 


1.  High  threat  or  short  reaction  time  weapons  response. 

2.  Sensor  systems  which  deliver  massive  amounts  of  raw  data  from  which  usable  in- 
formation must  be  derived  through  algorithmic  processes. 

3.  Repetitive,  and  very  subtle,  information  sources  where  changes  in  state  may  not 
be  detected  by  casual  or  distractable  observation.  Also  as  a  guard  against  mislead- 
ing information  or  disinformation  where  the  target  observation  system  has  known 
limitations. 

The  application  of  Expert  Systems  in  C3  is  ongoing;  however,  the  analyst  and 
commander  no  longer  know  the  man  who  is  feeding  them  the  information  on  which  they 
are  basing  decisions  (and  possibly  lives).  These  AI/Expert  Systems  are  generally  decision 
tree  or  probabilistic  based.  For  a  human  to  enter  into  this  system  in  the  middle  of  the 
cycle,  a  graphical  representation  of  the  AI  system's  knowledge  could  be  available.  In 
Decision  Support  Systems  (DSS),  a  common  presentation  vehicle  is  the  Probable  Fu- 
tures Map  [Ref.  3:  p.  121].  With  this  information,  a  commander  could  better  understand 
the  conclusions  and  recommended  options  from  his  intelligence  and  decision  support 
systems.  These  graphic  representations  are  easily  transmitted;  a  graphics  capable 
microcomputer  is  needed  to  display  them.  This  thesis  turns  one  of  DOD's  most  com- 
mon microcomputers,  the  Zenith  Z-100  series,  into  an  available  graphics  terminal. 

B.     WHY  THIS  PROJECT  IS  IMPORTANT 

This  C2  problem  needs  to  be  addressed  with  a  C4  solution.    In  a  time  when  rapid 
transfer  of  data  is  common-place,  a  commander  should  no  longer  have  to  depend  on  a 
hard  copy  of  a  map  or  chart  being  carried  to  his  subordinates  and  superiors.    Neither 
should  the  tactical  commander  be  tied  excessively  to  his  chart  bag  or  map  case. 
1.     Current  system 
a.     Requests 

The  current  system  requires  that  requests  for  cartographic  products  be 
submitted  to  DMA  or  one  of  its  military  distribution  centers  for  issue.  The  tactical 
commander  usually  needs  one  or  two  copies  of  each  map  in  each  of  the  areas  he  is  ex- 
pected to  operate.  This  relies  heavily  on  forethought  to  ensure  all  necessary  maps  are 
ordered  and  kept  on  hand.  The  burden  is  also  on  DMA  to  generate,  print,  store,  and 
then  distribute  maps  to  users.  Allowing  users  to  access  digitized  mapping  files,  develop 
their  own  projections  (usually  of  a  tactical  scale),  and  electronically  receive  the  product 
would  significantly  reduce  man-hours,  printing  costs,  and  warehousing  requirements. 
DMA  would  need  to  develop  some  user  friendly  programs  in  order  to  allow  access  and 
to  maintain  high  standards  for  their  cartographic  products,  but  this  could  be  easily  ac- 


complished  within  the  scope  of  current  assets.  The  recurring  theme  of  the  problem  this 
thesis  addresses  is  that  maps  and  charts  can  and  should  be  received  in  a  more  timely 
manner. 

b.     Contingency 

The  commander  and  his  staff  routinely  have  literally  hundreds  of  charts  and 
maps  which  are  carried  around  for  contingency  purposes.  These  maps  of  these  require 
continuous  updating  and  are  regularly  superceded  and  replaced.  The  requirement  to 
maintain  large  quantities  of  maps  adds  associated  logistic  and  manpower  burdens. 
There  is  a  need  for  an  alternate  means  of  obtaining  up  to  date  maps  and  charts  in  the 
fulfillment  of  a  contingency  requirement.1* 
2.     Suggested  Approach 

Commanders  should  be  able  to  transmit  their  situation  and  intentions  on  maps 
both  up  and  down  the  chain  of  command.  This  thesis  investigates  that  objective  using 
no  cost  or  government  proprietary  software  and  a  microcomputer  (the  Heath/Zenith 
100)  that  is  widely  available  and  well-suited  to  the  job.  The  ability  to  pass  maps  and 
charts  electronically  has  several  significant  benefits  to  the  users,  the  mapping  agencies, 
and  DOD  as  a  whole.   Some  of  these  possible  benefits  are  listed  below: 

1.  Immediate  availability  of  high  quality,  updated  maps  and  charts  to  lower  echelon 
commanders.  Though  not  being  able  to  replace  typeset  printed  maps,  an  elec- 
tronically transmitted  version  with  the  necessary  information  overlayed  or  imbed- 
ded would  be  an  improvement  over  lesser  quality  products. 

2.  Independence  from  some  of  the  logistics  tail  of  most  commands  and  all  staffs,  that 
is  chart  bags,  map  cases,  and  their  associated  files.  Maps  and  charts  for  locations 
not  in  a  commands  area  of  responsibility  (AOR)  could  be  called  electronically, 
rather  than  keeping  a  hard  copy  on-hand. 

3.  Decreased  requirement  for  DMA  printed  maps  and  more  time  available  to  order 
correct  maps  and  charts  before  the  detailed  planning  and  execution  phases. 

4.  Decrease  in  manpower  requirements  to  keep  chart  and  map  allowances  updated. 
The  emphasis  on  maps  and  charts  for  a  command's  AOR  being  always  up  to  date 
and  other  areas  being  available  on-call  electronically. 

5.  Better  utilization  of  common,  general  purpose  military  microcomputers  for  more 
missions. 


4  The  needs  of  a  tactical  commander  cannot  be  fulfilled  by  this  type  of  system  at  this  time. 
The  transfer  of  tactical  quality  maps  electronically  is  currently  an  option  using  specialized  graphics 
terminals  only,  however  this  capability  has  been  extended  to  some  major  Air  Force  C2  commands 
as  of  this  writing  (see  Chapter  I.B.3.a  below). 


a.  Electronic  distribution 

DOD  agencies  have  started  using  the  Defense  Mapping  Agencies  (DMA) 
database  of  digitized  maps.  This  is  usually  accomplished  with  a  dedicated  mainframe  and 
a  graphics  workstation.  Accessing  the  DMA  World  Data  Bank  II,  one  can  build  maps 
of  any  location  in  the  world.  To  build  the  map,  enter  the  center  of  the  desired  map  and 
then  the  directional  distances  from  the  center  to  be  displayed.  The  system  automatically 
retrieves,  draws,  and  then  scales  the  map.  Features  include  coastlines,  waterways,  poli- 
tical boundaries,  roads  and  railroads;  additionally,  latitude  and  longitude,  UTM,  or 
GEOREF  grid  systems  can  be  overlayed[Ref.  4:  p.  44]. 

b.  Generation 

In  addition  to  accessing  DMA  maps,  mainframe  computers  can  also  be  used 
to  m?,vtain  their  own  databases  of  graphics  software.  Cartographic  products  generated 
by  these  programs  could  be  sent  and  received  throughout  the  chain  of  command.  The 
ability  to  send  and  receive  graphics  products  up  and  down  the  chain  of  command  would 
result  in  consistent  quality  of  information  and  less  confusion  due  to  interpretation  of  the 
written  words  .  A  side  benefit  could  also  be  realized  with  the  distribution  of  other 
graphics  products  for  visual  affect  and  emphasis. 

c.  Existing  systems 

There  currently  exist  several  digitized  mapping  programs  for  microcomput- 
ers. Many  are  available  through  user's  groups  and  via  computer  bulletin  boards,  but 
all  of  them  have  limitations  which  will  not  fulfill  the  requirements  of  this  thesis.  A  brief 
review  of  some  of  these  products  follows. 

(1)  Map  Maker.  The  program  Map  Maker  produces  two  forms  of 
quantitative  maps:  choropleth  (area  coloring)  and  graduated  circles.  Any  set  of  statis- 
tical values  may  be  displayed  for  its  corresponding  geographic  area.  Map  areas  are 
limited  to  states,  counties,  census  tracts,  or  areas  defined  by  the  user.[Ref.  5:  p.  67]  This 
program  is  typical  of  those  developed  for  the  social  sciences  and  demographics.  Its  re- 
solution and  accuracy  would  probably  be  inadequate  for  military  purposes. 

(2)  World  Map.  This  software  allows  users  to  generate  a  world  map  on 
the  screen  and  even  to  zoom  into  various  areas.  Only  boundary  lines  are  drawn  on  the 
map  and  there  are  no  details.  The  map  is  very  good  for  allowing  the  user  to  set  a  latitude 
and  longitude  and  then  zoom  in  on  the  area  in  question.  A  number  of  cities  and  capitals 
are  given  and  can  be  located  and  zoomed  in  on  from  the  world  map.  [Ref.  5:  p.  83]  This 


5  A  picture  is  worth  a  thousand  words. 


program  could  be  useful  to  the  strategic  level  planner  who  is  only  concerned  with  low 
cartographic  resolution  maps.  Lack  of  data  points  would  seriously  hinder  lower  level 
planners  who  require  greater  accuracy  and  detail. 

(3)  World  Digitizer.  Another  new  map  generation  program  is  World 
Digitizer  which  has  a  similar  capability  to  World  Map,  described  above.  It  is  written  in 
the  language  C  and  performs  all  of  its  functions  very  quickly.  The  data  it  uses  to  gen- 
erate maps  is  composed  of  one  million  connected  latitude  and  longitude  points.  This  is 
the  first  program  reviewed  which  specifically  warns  the  user  of  its  inaccuracies.  Its  ap- 
plication to  strategic  and  operational  planners  uses  is  possible. 

(4)  MicroDEM,  formerly  Terrain  Analysis.  This  program  provides  dig- 
ital topographical  support.  The  program  uses  Digital  Terrain  Elevation  Data  (DTED) 
Level  I  produced  by  DMA,  but  the  characteristics  of  the  data  limit  its  capability  and 
require  careful  analysis  of  its  results.  The  program  can  dump  to  a  printer  line  of  sight 
profiles,  weapons  or  sensor  masking  plots,  color  tinted  elevation  maps,  slope  maps,  and 
three  dimensional  oblique  views.  Data  sets  used  by  the  computer  cover  15  minutes  of 
longitude,  which  corresponds  to  a  standard  tactical  map.  Programs  are  available  for  the 
Fulda  Gap  (16  disks),  the  Korean  DMZ  (5  disks),  and  Fort  Irwin/ West  Point  (11  disks). 
[Ref.  5:  p.  18]  This  program  is  highly  accurate  and  is  updated  regularly.  However,  the 
logistics  trail  to  provide  replacement  and  corrected  disks  would  represent  no  major  im- 
provement over  the  existing  system  with  regards  to  logistics,  manpower  burden,  nor 
timeliness.  Exploration  of  this  system  resulted  in  this  thesis  advocating  the  use  of 
mainframe  computers  to  generate  the  maps  required,  whether  organically  produced  or 
drawn  from  DMA  data.  Regardless  of  the  microcomputer  advocates'  claims  that  their 
machines  can  do  it  all,  some  jobs  remain  too  large.  The  microcomputer  is  better  used  to 
display  a  map  the  mainframe  has  stored  for  it,  and  then  to  print  it. 

3.    Direction  of  Computer  Mapping 

There  exist  two  distinct  categories  in  which  the  military  commander  or  his  staff 
would  need  to  generate  maps.  The  first  is  the  strategic  and  operational  levels  of  com- 
mand. The  requirement  would  be  for  large  area,  small  scale  maps  on  which  a  commander 
could  place  symbology,  icons,  or  text  for  broad  direction  and  situational  reporting. 
Accuracy  and  resolution  quality  would  be  secondary  to  convenience  and  speed  of  use. 
Ideally,  situation  reports  and  concept  of  operation  maps  could  be  prepared^  easily  stored 


6  Operational  level  of  command  can  be  roughly  equated  to  the  theater  level  or  the  area  in 
which  a  corps  commander  would  operate. 


and  instantly  accessible  to  subordinates  and  superiors.  The  maps  could  readily  be  played 
back  by  remote  units  requiring  only  a  small  graphics  capable  computer  and  a  modem 
(Ref.  6).  The  second  situation  occurs  when  lower  level  users  employ  maps  and  charts 
for  tactical  purposes.  The  programs  mentioned  in  the  previous  section  either  lack  suffi- 
cient resolution  or  require  dozens  of  computer  data  disks  to  present  a  specific  area.  The 
resolution  problem  is  unacceptable,  when  resolution  needs  to  be  10  meters  or  less.  The 
multiple  disk  problem  offers  no  logistical  or  timeliness  improvement  over  the  current 
system  of  carrying  bundles  of  charts  or  maps.  This  situation  would  require  that  the 
maps  be  created  from  a  highly  accurate  and  continuously  updated  cartographic  data- 
base. Access  to  DMA  online  digitized  maps  would  be  a  necessity.  Some  attempts  at 
integrating  the  DMA  data  bases  into  a  real-time  enviroment  are  being  attempted.  A 
sampling  of  these  programs  follow. 

a.  TRACE 

The  U.S.  Air  Force  is  currently  purchasing  an  automated  decision  support 
tool  for  C3I  called  Tactical  Resource  Allocation  for  Combat  Effectiveness  (TRACE). 
This  system  is  available  from  Lockheed  Missiles  and  Space  Company  or  through  Chro- 
matics, Inc.  The  object  is  to  develop  a  flexible  and  transportable  system  which  can  allow 
a  command  center  to  reduce  time  in  resource  planning  and  allocation.  TRACE  runs  on 
a  Digital  Electronics  Corporation  (DEC)  VAX  computer  with  the  Chromatics  CX1536 
High  Resolution  Graphics  display.  The  prograrnming  is  in  Fortran  and  Graphical  Kernel 
System  (GKS).  This  combination  of  hardware  and  software  allows  real-time  generation 
of  maps  using  DMA  digitized  data.[Ref.  4:  p.  44,  46]  Though  this  system  works  at  the 
command  level,  it  is  too  hardware  dependent  ever  to  become  available  ?t  the  tactical 
level.  Soon,  this  system  will  allow  the  strategic  and  operational  planners  to  generate 
high  quality  maps  and,  hopefully,  to  disseminate  them  to  lower  echelon  commanders. 

b.  National  Marine  Fisheries  Services 

The  National  Marine  Fisheries  Services  (NMFS),  which  operates  under  the 
National  Oceanagraphic  and  Atmospheric  Agency  (NOAA),  has  been  developing  the 
capability  of  a  small  graphics  capable  computer  to  display  DMA  or  NOAA  maps  and 
charts.  The  computer  emulates  a  Tektronix  4010  Graphics  Display  (similar  to  the  em- 
ulator used  in  this  thesis)  and  the  reports  indicate  that  the  concept  is  feasible.  Opera- 
tional evaluation  was  conducted  at  Galveston,  Texas.  [Ref.  7] 
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c.     Future  DMA  products 

DMA  is  in  the  process  of  developing  a  film  digitization  capability  which 
would  be  used  in  the  future  for  a  digital  point  positioning  data  base  product. [Ref.  8] 
Access  to  this  type  of  information  would  be  available  via  the  same  means  as 
cartographic  data  and  could  be  similarly  displayed.  This  is  another  tactical  tool  which 
can  be  utilized  and  should  be  explored  in  the  future. 


li 


II.     iMETHODOLOGY 

A.     APPROACH 

This  thesis  will  identify  all  components  of  a  Low  Cost  Graphics  (LO-CO-GRAF) 
system  to  address  the  problem  of  generating  maps,  transferring  the  maps  between  users, 
and  producing  a  hard  copy  of  that  map  from  a  command,  control,  communication 
and  computer  (C4)  perspective.  Computing  and  communicating  between  computers 
and  data  networks  will  be  the  central  focus  of  the  approach,  with  an  additional  re- 
striction that  this  be  a  no/low  cost  solution  to  the  problem.  With  the  appropriate 
set  of  equipment  and  softwfe  attributes,  commanders  can  enlist  the  aide  of  com- 
puters to  ease  some  of  the  burdens  of  command  and  control.  The  combined  use  of 
mainframe  computing  power  and  the  ability  to  communicate  or  translate  that  power 
to  smaller  more  accessible  computers  will  provide  a  valuable  tool  to  the  commander  and 
the  command  and  control  function.  The  set  of  remote  "source"  systems  that  generate 
the  graphics,  local  microcomputers,  communications  software,  the  graphics  terminal 
emulator  software  program  and  the  software  required  to  print  out  graphics  products 
will  comprise  the  LO-CO-GRAF  system.  As  seen  in  Figure  3,  which  provides  an  over- 
view of  the  system  architecture  and  components,  communications  software  will  enable 
each  remote  terminal  to  transfer  data  from  the  mainframe  computer  (or  other  graphics 
source  system)  to  other  user  terminals.  The  programs  required  to  send  the  electronic 
maps  are  available  for  most  microcomputers  and  are  an  essential  component  of  the 
system.  The  program  required  to  playback  or  display  the  maps  can  be  transferred  within 
the  system's  terminals,  as  well  as  the  printing  programs. 
1.     Advantages 

The  LO-CO-GRAF  system  will  take  advantage  of  the  high  quality  graphics 
programs  and  large  storage  potential  characteristically  available  on  mainframe  com- 
puters, while  using  them  to  perform  the  calculating  and  plotting  functions  required  to 
produce  maps  and  other  high  quality  graphics.  Taking  this  approach  will  overcome 
some  of  the  problems  encountered  by  other  map  generation  programs  which  tried  to 
perform  all  of  the  functions  on  the  microcomputer.  Utilizing  a  mainframe  also  takes 
advantage  of  the  fact  that  the  database    is  constantly  being  updated  by  the  Defense 
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Figure  3.      The  LO-CO-GRAF  System  architecture. 

Mapping  Agency,  providing  up-to-date  information.7  The  C2  community  must  be  able 
to  access  this  information  from  remotely  located  terminals  in  order  to  obtain  the  greatest 
benefits.  With  the  aid  of  a  communications  software  package  and  terminal  emulator 
this  can  be  accomplished  at  little  or  no  cost  by  utilizing  equipment  assets  already 
available  to  most  organizations. 
2.    Distributed 

Doing  the  work  remotely  is    a    major    point   where    LO-CO-GRAF    departs 


7  Being  able  to  access  and  process  the  DMA  databases,  that  is  the  digitized  cartographic  pro- 
ducts, as  they  become  available  circumvents  the  delay  associated  with  the  logistics  lag  tunc  involved 
with  ordering  maps. 
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from  similar  graphics  programs. 8  By  accessing  a  remote  source  which  will  actually 
generate  the  derived  graphics  and  by  keeping  that  function  separate,  the  microcomputer 
is  free  from  the  major  task  of  maintaining  the  sizable  database  required  to  generate 
the  maps  and  avoids  the  problem  of  trying  to  manipulate  and  process  all  that  data. 
After  downloading  the  high  quality  graphics  products  from  mainframe  computers  and 
other  sources,  it  can  be  translated  to  a  form  that  can  be  understood,  displayed,  stored, 
redisplayed,  and  transmitted  to  other  users.  There  are  commercial  and  military  hard- 
ware and  software  packages  available  that  provide  the  capability  to  process  DMA 
data  or  generate  maps  and  other  higher  level  graphics.  Unfortunately  these 
systems  are  very  costly  and  require  too  much  memory  storage  capability  or  too 
many  hardware  enhancements  to  be  widely  employed  without  incurring  large  costs  to 
implement.  The  objective  of  this  thesis  is  to  demonstrate  that  a  system  could  be  made 
widely  available  at  no  cost  to  the  users,  by  taking  advantage  of  existing  assets. 

To  accomplish  this  goal,  it  is  necessary  to  make  a  few  starting  assumptions. 
First,  what  is  the  working  environment?  And  then,  what  equipment  can  be  expected 
to   be  available  in  the  C2  community? 

B.    ASSUMPTIONS 

The  first  assumption  is  that  the  LO-CO-GRAF  system  should  be  capable  of 
transmission  over  telephone  networks.  This  type  of  operation  will  allow  the  head- 
quarters or  the  central  C2  controlling  node  to  bring  in  other  new  members  and  share 
the  graphics  among  a  set  of  operational  units  or  commands.  The  only  requirement  is 
that  that  unit  have  a  similar  set  of  hardware  and  software  available. 

Some  hardware  is  universally  available  to  support  the  C2  components  wishing  to 
use,  produce  and  transmit  graphics  products.  The  software  required  will  be  intro- 
duced or  provided  as  a  by-product  of  this  thesis.  The  real  contribution  of  the 
LO-CO-GRAF  system  is  the  ability  not  only  to  obtain  the  graphics,  but  also  to 
transmit  any  maps  generated  along  with  the  software  necessary  to  use  it.  Some  as- 
sumptions follow  about   the  working   environment  and  the  assets  available. 


8  Microdem  and  Terranal,  for  example,  use  data  which  has  been  processed  and  prepared 
to  enable  a  small  computer  to  then  generate  maps  locally.  One  problem  with  this  process  is  that 
you  need  to  keep  all  the  data  on  hand  locally  and  then  reprocess  it  as  needed.  The  data  disks 
required  are  very  cumbersome  and  are  just  as  difficult  to  keep  current  logistically  as  paper  maps. 


14 


1.  Sources 

High  quality  graphics  products  are  available  on  many  mainframe  computers 
which  are  capable  of  processing  raw  data  and  generating  maps.  Most,  if  not  all, 
mainframe  computers  have  resident  programs  to  perform  high  quality  graphics  func- 
tions. The  graphics  programs  are  either  capable  of  generating  their  own  maps,  as  in  the 
case  of  Display  Integrated  Software  System  and  Plotting  Language  (DISSPLA)  pro- 
gram, or  are  capable  of  processing  DMA  data  to  plot  maps  from  raw  data. 

In  the  case  of  a  remotely  located  C2  terminal,  the  mainframe  will  not  be  acces- 
sible by  a  direct  connection  to  the  microcomputer.  Connecting  will  require  access 
through  some  communications  system  in  order  to  make  the  graphics  program  available. 
"Available"  means  obtaining  access  to  the  mainframe  through  a  modem  and  communi- 
cations software  package  or  communicating  to  some  other  graphics  generating  facility, 
such  as  those  available  on  the  Defense  Digital  Network  (DDN).  In  either  case,  the 
operative  word  is  available.  An  additional  requirement  for  this  thesis  is  to  implement 
LO-CO-GRAF  at  no  additional  cost.  Next,  the  problem  of  establishing  communi- 
cations between  the  remote  mainframe  (or  other  map  source)  and  the  local 
microcomputer  must  be  addressed  and  resolved. 

2.  Communications 

Communications  software  is  readily  available  at  no  cost  as  freeware  or  Gov- 
ernment proprietary  software  and  in  most  cases  is  already  available  on  a  mainframe 
computer  available  to  the  potential  users.  If  no  communication  software  package  is 
available,  one  must  be  obtained,  again  at  no  cost,  in  order  to  stay  within  the  low  cost 
(no  cost)  objective.  This  thesis  assumes  there  is  a  communications  software  package 
available  which  will  enable  communications  between  the  remote  map  generating  system 
and  the  local  microcomputer. 

For  the  case  where  no  communications  system  is  available  to  provide  access 
to  the  mainframe,  instructions  for  obtaining  the  software  will  be  provided  within  this 
thesis.  The  software  must  be  adaptable  to  as  many  different  mainframe  computers  as 
possible  to  allow  access  to  all  the  many  types  of  graphics  source  machines  available. 
The  communications  software  must  also  provide  for  communications  between  the 
graphics  sources  and  to  the  microcomputer. 

3.  Microcomputer 

The  microcomputer  must  be  capable  of  translating  and  processing  the 
graphics    data.    The  Zenith  Data    System  Z-100  microcomputer  is  both  capable  and 
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available.  There  are  many  Z-100  computers  in  the  military  inventory  which  are  not 
utilized  to  their  full  capability.9  The  Z-100  was  chosen  because  it  has  very  good  built-in 
graphics  capabilities,  which  will  be  discussed  later  in  greater  detail  in  Chapter  III. 

To  take  full  advantage  of  the  resident  graphics  capability  of  the  Z-100,  a 
software  program  will  be  developed  and  documented  as  part  of  this  thesis  to  make  it 
emulate  a  standard  high  quality  graphics  terminal.  Through  emulation,  the  Z-100  will 
gain  the  ability  to  process,  display,  and  store  (map)  graphics.  After  storing  the  data, 
the  last  step  is  to  be  able  to  recall  or  redraw  those  saved  images  as  well  as  print  them 
out  on  paper. 
4.     Printers 

The  last  assumption  is  that  there  will  be  a  requirement  to  print  any  maps  or 
other  images  which  are  generated  by  LO-CO-GRAF.10  Choosing  a  graphics  screen 
dump  program  which  applies  to  several  of  the  more  common  military  printers  will  pro- 
vide a  way  to  print  any  map  images  saved  by  the  terminal  emulator  program. 


9  The  major  reason  for  not  fully  utilizing  the  Z-100  capabilities  is  that  they  are  neither  soft- 
ware nor  hardware  compatible  with  the  more  recent  and  popular  International  Business  Machine 
(IBM)  personal  computer  (PC)  machines.  The  differences  are  examined  in  detail  in  Chapter  III.C. 

10  There  are  many  dot  matrix  printers  throughout  the  DOD  in  both  militarized  and  com- 
mercial versions.  The  Epson  MX,  Okidata  Microline,  and  Zenith  MPI-99/150  series  dot  matrix 
printers  are  examples  of  standard  DOD  printers. 
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III.     TECHNICAL  EXPLANATION 

A.     MAP  GENERATION 

The  ability  to  generate  maps  for  strategic  or  theater  level  operations  is  commonly 
available  in  mainframe  graphics  programs.  The  mapping  characteristics  may  include  a 
variety  of  coastlines,  political  boundaries,  and  waterways,  as  well  as  selection  between 
the  different  types  of  projections.  The  major  limitation  is  that  only  a  limited  number  of 
data  points  have  been  saved  for  the  maps  to  be  drawn  from.  Two  unique  resolution 
problems  are  encountered  while  creating  maps.  First,  the  aforementioned  lack  of  data 
points  can  only  generate  maps  with  resolution  measured  in  kilometers  (possibly  fractions 
of  kilometers).  An  example  of  this  type  of  resolution  problem  can  be  seen  in  Figure  4. 
Secondly,  display  resolution  is  limited  by  the  type  of  computer  monitor  being  used  and 
also  by  printer  resolution  characteristics. 
1.     Resolution  Problems 

The  standard  defmition  of  resolution  is  the  smallest  distance  between  two  dif- 
ferent points  that  is  distinguishable.  In  printer  terms,  the  expression  used  is  "dots  per 
inch"  or  dpi  (a  typical  laser  printer  can  perform  300  dpi  or  resolution  to  1/300  of  an 
inch).  For  computer  monitors,  resolution  is  stated  in  the  number  of  pixels,  that  is,  the 
number  of  points  on  a  screen  displayed  vertically  and  horizontally.  The  number  of  dots 
per  inch  is  not  fixed  by  the  computer  screen,  though.  Just  as  a  television  picture  looks 
less  grainy  on  a  small  screen,  a  computer  monitor  with  a  13-inch  screen  will  look  better 
than  a  19-inch  screen.  This  is  because  the  picture  is  really  made  up  of  a  fixed  number 
of  pixels,  the  larger  the  screen  then  the  further  apart  the  dots  will  be  [Ref.  9:  p.  34]. 
Resolution  can  be  changed  by  the  user  in  both  the  horizontal  and  vertical  by  adding 
hardware  upgrades  to  the  graphics  circuitry,  therefore  manufacturers  refer  to  the  total 
number  of  pixels  displayed.  A  common  example  would  be  the  Color  Graphics  Adapter 
(CGA),  which  has  a  color  resolution  of  320  by  200. 

Table  1  presents  a  sampling  of  devices,  their  actual  resolution,  and  their  pres- 
entation characteristics.  These  numbers  must  naturally  be  compared  to  the  visual  acuity 
of  the  human  eye.  Typically,  a  person  can  distinguish  objects  one  degree  apart  at  six 
feet.  Human  vision  remains  highly  dependent  on  distance,  contrast,  color  and  shading, 
shapes,  brightness  and  darkness,  and  the  viewer's  age  (Ref.  10). 
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Figure  4.      Example  of  resolution  problems:     Map  of  Washington,  DC  area. 

Returning  to  the  television  example,  a  typical  television  monitor  only  produces 
200  lines  of  resolution,  much  less  than  that  possible  with  a  graphics  adapter.  Yet  to  the 
eye  it  is  more  than  sufficient  to  portray  an  image.  The  reason  for  this  is  the  large  number 
of  colors  or  shadings  being  used.  This  multi-color,  low  resolution  technique  is  excellent 
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Table  1.     SAMPLE  RESOLUTIONS 


Screen  Resolution 

Actual  Resolution 

Lines/ char 
@  12  pt 

320X200  on  13" 

36  ppi  (horizontal) 
30  ppi  (vertical) 

5 

640X480  on  13"  (Z120) 

72  ppi 

12 

1024  X  768  on  16" 

90  ppi 

15 

1536  X  1152  Chromatic 
CX1536  (TRACE) 

24 

Dot  matrix  printer 
(standard  9-pin) 

up  to  240  dpi 

40 

24-pin  dot  matrix  printer 

up  to  360  dpi 

60 

Laser  printer 

300  dpi  (typical) 

50 

Typesetter 

1200  dpi 

200 

Taken  in  part  from  [Ref.  9:  p.  36]  and  manufacturer's  specifications. 


when  displaying  real-life  images,  but  inadequate  for  text  images  [Ref.    9  :  p.  35].    The 
problem  is  heightened  by  the  intense  resolution/accuracy  requirements  needed  for 
mapmaking.    The  anti-aliasing  schemes  used  to  improve  the  appearance  of  text  on  a 
monitor  would  only  introduce  error  into  cartographic  representations. 
2.     DISSPLA 

The  graphics  package  available  on  the  IBM  3033  mainframe  computer  at  NFS 
is  the  DISSPLA  program.  This  system  was  developed  by  Integrated  Software  Systems 
Corporation  (ISSCO)  of  San  Diego  and  is  widely  used  throughout  the  Navy,  DOD,  in- 
dustry, and  other  academic  institutions  [Ref.  11].  According  to  DISSPLA,  any  desired 
graphics  product  can  be  achieved  within  one  to  two  hours,  using  the  interactive  system. 
Some  of  the  products  include  specialized  business,  cartographic  projections  (of  interest 
to  this  thesis),  and  a  dynamics  program.  All  of  which  are  detailed  for  practical  applica- 
tions in  the  DISSPLA  User  Guide  [Ref.  12]. 

Automated  graphics  is  a  powerful  and  useful  computer  application  of 
significant  importance  to  distributive  computing  and  wargaming  in  the  military.  The 
capability  to  plot  computer  generated  maps  on  demand  is  an  essential  tool  for  opera- 
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tional  commanders,  as  well.  There  are  many  software  packages  which  provide  programs 
of  commands  and  subroutines  to  produce  very  powerful  graphics  outputs.  The 
geographic  data  required  to  plot  the  maps  is  stored  in  mass  storage  in  several 
resolutions[Ref.  12:  Part  D],  which  can  be  called  to  generate  maps  of  various 
projections. 

a.     Programming 

DISSPLA  was  developed  using  Fortran  IV  constructs.  Current  Fortran 
compilers  use  Fortran  77  or,  if  an  IBM  system,  VS  Fortran.  Both  are  fully  backwards 
compatible  and  have  the  greater  variety  of  options  for  entering  data  which  aids  in 
cartographic  design  and  engineering. 

The  DISSPLA  package  is  actually  a  library  of  FORTRAN  subrou- 
tines which  can  be  called  and  arranged  with  other  FORTRAN  source  code  to  gen- 
erate the  desired  map.  It  required  a  great  deal  of  time  to  learn  how  to  organize  these 
subroutines  to  generate  maps  and  plotting  a  few  maps  of  different  theaters  of  opera- 
tion to  show  the  power  of  this  DISSPLA  option. 

The  process  of  calling  subroutines  at  various  levels  within  the  DISSPLA 
package  is  perhaps  the  most  difficult  concept,  but  not  the  first  that  can  cause  trouble. 
To  use  DISSPLA  means  one  will  interface  through  a  set  of  more  than  300  user-  call- 
able subroutines.  The  subroutines  access  a  network  of  usually  invisible  (except 
when  an  error  condition  occurs),  internal  sub-subroutines  which  communicate  with 
each  other  using  blocks  of  more  than  200  variables.  As  can  be  seen,  calling  a  subrou- 
tine is  no  simple  matter.  The  logic  flow  in  DISSPLA  is  unidirectional  through  more 
than  twenty  levels  of  subroutines. 

By  levels,  it  is  meant  that  a  call  on  one  subroutine  may  do  nothing  more 
than  set  a  parameter  or  flag  a  variable  for  use  by  another  subroutine,  or  a  subroutine 
occurring  later  on  in  the  program.  Calling  a  subroutine  that  depends  on  another 
subroutine  which  has  not  already  been  called  will  cause  you  to  go  into  computer 
"Never- Never"  land.  Fortunately,  to  generate  maps  one  will  only  have  to  specifically 
address  four  kinds  of  routines  to  change  to  proper  levels. 

The  program  listings  in  Appendixes  A  and  B,  emphasize  comments  which 
show  the  transitions  between  programming  levels.  Using  the  programs  listed  in  Ap- 
pendix A,  one  will  not  need  to  know  a  great  deal  about  the  levels  to  generate  maps, 
but  should  understand  that  they  exist  and  can  cause  great  difficulty  when  generating 
complicated  plots  if  they  are  not  accessed  in  the  correct  order.[Ref.  11] 
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b.  Running  DISSPLA 

To  use  DISSPLA  under  VM/CMS,  one  must  link  to  the  support  disks 
which  contain  the  data  files.  This  involves  establishing  appropriate  input  and 
output  files,  file  definition  statements,  and  text  library  programs,  which  is  a  tedious  and 
time  consuming  process.  There  is  an  execll  ,  DISSPLA  EXEC,  that  must  be  used  to 
actually  run  a  program  and  link  to  all  the  appropriate  files  and  create  the  correct  envi- 
ronment to  work  in  DISSPLA. 

An  on-line  help  file  is  available  by  typing  "disspla  ?".  Although  this  file  is 
helpful,  it  does  not  make  it  easier  to  create  three  dimensional  plots  (maps  are  two 
dimensional  projections  of  three  dimensional  data  points)  nor  does  it  address  how  to 
generate  a  map  specifically.  The  most  valuable  source  of  information  for  plotting  maps 
is  contained  in  the  DISSPLA  Pocket  Guide  [Ref.  12:  Part  D].  It  contains  several  ex- 
ample programs  with  more  information  about  the  calling  of  map  plotting  subroutines. 

c.  DISSPOP  option 

When  the  DISSPOP  option  of  DISSPLA  is  called,  the  output  is  a  device 
independent  plot  file,  rather  than  an  actual  plot.  This  file  is  called  a  metafile  and  is  highly 
compressed.  It  can  be  interpreted  by  one  of  a  selection  of  post-processor  programs  for 
output  to  a  particular  device.  [Ref.  12:  p.  F-l]  Exercising  the  DISSPOP  option,  or  a 
similar  capability  under  a  different  graphics  program,  a  commander  could  generate  the 
map  or  chart  with  any  necessary  information  attached  and  then  store  it.  Any  subordi- 
nate or  superior  with  a  graphics  device  listed  in  the  DISSPOP  post-processor  device 
menu  could  then  instantly  retrieve,  display,  and  print  (if  they  also  have  that  capability) 
these  maps  and  charts.  The  use  of  a  device  independent  plot  file  will  have  to  be  a  ca- 
pability included  in  a  command  center's  map  generation  program. 

B.     COMMUNICATION 

The  second  part  of  the  solution  involves  establishing  a  way  to  communicate  be- 
tween the  mainframe  and  a  remote  microcomputer.  Computer  to  computer  communi- 
cations requires  a  working  knowledge  of  the  technical  characteristics  of  both  machines, 
a  modem,  and  a  basic  understanding  of  communications  software.  First,  a  discussion 
of  the  functions  of  the  modem  and  how  it  provides  the  connection  between  the  remote 
graphics  generating  system  and  the  microcomputer. 


1 1  An  exec  is  an  executable  file,  which  when  called  will  initiate  programs  and  configure  your 
operating  system  or  virtual  machine  for  a  specific  task. 
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1.  Modems 

There  are  two  basic  modem  configurations,  internal  and  external.  Elec- 
trically there  is  no  difference  and  the  procedures  that  follow,  as  well  as  the  software  to 
be  provided/ introduced,  will  work,  with  either  variety.  All  modems  are  rated  in  terms 
of  their  transmission  speed.  The  ratings  are  in  baudl2  (e.g.  300,  1200,  2400,. .etc.), 
which  refers  to  the  number  of  bits  per  second  the  modem  is  capable  of  transmitting  or 
receiving.  A  1200  baud  modem  will  transmit  and  receive  data  four  times  faster  than 
a  300  baud  modem,  and  half  as  fast  as  one  rated  at  2400  baud.  Most  communications 
software  systems  today  allow  connection  at  any  speed,  but  the  faster  the  better. 

2.  Communication  Software 

A  communications  software  program  is  used  to  access  a  communications 
network  or  remote  system.  This  allows  the  microcomputer  to  dial  the  necessary 
telephone  numbers,  establish  an  electrical  connection,  and  then  communicate  with  the 
remote  system.  The  remote  system  may  be  a  mainframe  computer,  another 
microcomputer  or  a  data  communications  network,  like  the  Defense  Data  Network 
(DDN).  The  main  function  of  this  software  is  to  make  the  remote  system  recognize  your 
microcomputer  as  an  input/output  terminal. 

By  electrically  looking  like  an  input/output  terminal,  the  microcomputer  can 
talk  to  the  remote  system  over  telephone  lines  as  if  it  were  connected  (hardwired)  to  the 
other  computer  system  directly.  Most  communications  software  programs  will  also 
allow  transfer  of  files  and  programs  from  the  microcomputer  to  the  remote  system  and 
vice  versa.  The  file  transfer  feature  will  play  an  important  part  in  the  LO-CO-GRAF 
network  so  it  is  important  to  select  a  program  which  utilizes  a  standard  communications 
protocol.  The  communications  software  package  selected  for  this  thesis  has  been  de- 
veloped for  over  200  different  computers  and  microcomputers. 

3.  KERMIT 

KERMIT  actually  stands  for  K110  Error-free  Reciprocal  Microcomputer 
Interconnection  over  Teletype  (TTY)  lines.  This  computer  communications  protocol 
designation  was  established  when  CP/M  was  the  preferred  microcomputer  operating 
system  and  it  was  not  changed  as  the  system  was  later  developed  for  use  with  other  disk 
operating  systems  (DOS). 


12  Baud  rate  is  a  measurement  of  the  capacity  of  a  communications  channel  to  pass  informa- 
tion. 
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KERMIT  was  developed  and  written  at  the  Columbia  University  Center  for 
Computing  Activities  as  a  packet  switched  file  transfer  and  communications  pro- 
gram. KERMIT  is  not  necessarily  better  than  other  programs  but  it  is  free  and  it 
has  been  adapted  for  use  on  many  micro,  mini,  and  mainframe  computers.  The  partial 
list  in  Figure  5  shows  a  few  of  the  more  popular  versions. 

Every  version  that  has  been  implemented  is  available  from  the  Columbia 
University  KERMIT  Distribution  Center.  13  The  program  can  be  downloaded  by  any 
file  transfer  system  with  a  modem  connection  or  by  accessing  the  distribution  center 
through  an  electronic  data  system  like  the  Defense  Data  Network  (DDN).  A  com- 
plete set  of  instructions  are  available  (Appendix  D)  which  provide  all  the  instructions 
necessary  to  access  the  KERMIT  archives.  Once  you  have  obtained  a  copy  of 
KERMIT  it  must  be  set-up  with  the  correct  parameters  to  use  it  in  the  LO-CO-GRApII 
system.  14 

4.     Utilization 

There  is  a  very  exhaustive  manual  available  in  disk  format  which  explains  all 
the  parameters  and  options  for  using  KERMIT.  It  is  beyond  the  scope  of  this  thesis 
to  explore  all  the  abilities  of  the  program  itself.  An  instruction  guide  which  explains 
all  the  steps  necessary  to  operate  KERMIT,  as  required  for  the  LO-CO-GRAPH  sys- 
tem, appears  as  Appendix  E. 

The  KERMIT  instruction  guide  is  written  specifically  to  allow  connection  of  the 
Zenith  Z-100  to  the  International  Business  Machines  (IBM)  370  mainframe.  It  is 
not  necessary  to  know  anything  more  about  KERMIT  to  use  it  as  the  communi- 
cations software  in  this  system.  Minor  modifications  to  the  set-up  procedure  will  al- 
low connection  to  the  Defense  Data  Network. 

Connection  to  the  DDN  and  or  mainframe  will  allow  access  to  a  graphics 
program  designed  to  generate  high  quality  graphics  and  maps.  These  programs 
require  a  graphics  terminal  or  workstation  quality  monitor  in  order  to  display  the 
graphics.  This  leads  into  the  next  area  of  the  project.  It  is  necessary  now  to  make  the 
remote  graphics  source  system  think  the  microcomputer  is  a  graphics  processing  termi- 
nal. 


13  The  center  maintains  a  file  (Appendix  C)  on  their  computer  which  contains  a  much 
more  comprehensive  list  of  KERMIT  applications  and  provides  ail  the  information  needed  to 
fmd  the  correct  version  for  your  computer. 

14  This  will  be  discussed  at  length  in  Chapter  IV. 
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MACHINES fS) 

OPERATING 

SYSTEM 

LANGUAGE 

Micros  and  Workstation 

» 

Apollo 

Aegis 

Pascal 

Apple  II 

DOS  3.  3  or 

ProDos 

6502  Assembler 

Atari  ST  Series 

GEM 

C 

Commodore  64 

DOS 

CROSS  (or  FORTH*) 

DEC  Professional-350 

P/OS 

Bliss 

Honeywell  L6/10 

MS-DOS 

MASM 

IBM  PC  family 

PC  DOS 

Lattice  C 

OS9/68000  Portable 

various 

Assembler 

Sirius  1/Victor  9000 

MS-DOS 

C 

TRS-80  Model  4 

TRSDOS 

ASM 

Tandy  2000 

MS  DOS 

MASM 

TRS-80  I  and  III 

TRSDOS 

Z80  Ass. 

Minis  and  Mainframes  - 

Cray-1,  Cray-XMP 

CTSS 

Fortran-77 

Data  General 

A0S/VS  with  MV/UX 

C 

DECSYSTEM-20 

TOPS-20 

MACRO- 20 

Honeywell  6000 

DTSS 

Virtual  PL/ I 

Hewlett-Packard  3000 

MPE 

SPL 

IBM  370  Series 

VM/CMS 

Pascal/VS 

IBM  370  Series 

MTS 

Asm,  Pascal 

Sperry/Univac-1100 

EXEC 

Assembler 

VAX 

VMS 

C 

Figure  5. 


Partial  list  of  available  KERMIT  applications 


C.     TERMINAL  EMULATOR 

There  are  many  types  and  makes  of  microcomputer  available  within  the  DOD 
community.  Creating  a  way  to  transport  graphic  images  among  all  of  them  would  in- 
volve many  problems.  For  this  reason  the  selection  of  a  microcomputer  on  which 
to  base  the  emulation  program  is  a  critical  decision  point  in  this  thesis  research. 
This  choice  is  dictated  by  the  availability  and  cost  of  the  microcomputer  as  well  as  its 
resident  graphics  handling  capabilities.  Why  select  the  Heath/  Zenith  Z-100  over  the 
IBM-PC?  One  of  the  greatest  assets  of  the  Z-100  computer  is  its  high-resolution 
graphics  capability  which  is  made  easy  to  use  by  the  availability  of  powerful  graphics 
statements  in  the  Heath/Zenith  (Z-BASIC)  implementation  of  Microsoft  BASIC  [Ref. 
13:  p.  77].  The  following  sections  provide  a  short  history  and  detailed  analysis  of  this 
decision. 


24 


1.  Z-100  versus  IBM  PC 

The  IBM  Personal  Computer  (PC)  was  introduced  in  late  1981.  Because  of 
IBM's  success  in  the  mainframe  market  place  and  the  fact  that  their  name  was  nearly 
synonymous  with  'computer',  it  took  the  microcomputer  world  by  storm  and  quickly 
became  the  industry  standard.  To  become  the  'standard'  was  an  important  devel- 
opment in  the  then  new  marketplace.  The  biggest  change  it  introduced  was  the  idea 
of  third  party  software  development.  Until  then  almost  all  software  was  developed 
or  sponsored  for  development  by  each  computer  manufacturer  for  exclusive  use  with 
their  computer. 

The  fact  that  other  parties  could  now  write  and  produce  software  for  use 
on  a  set  of  new  standard  computers  was  both  a  blessing,  for  all  the  new  microcom- 
puters that  were  to  come,  and  a  disaster  for  all  that  had  already  arrived.  IBM  had  done 
something  different  in  their  computer  architecture  that  made  it  vastly  different  [Ref. 
14:  p.  47]  from  nearly  all  previously  designed  computers  including   the  Z-100  . 

2.  Differences 

The  biggest  differences  appear  in  the  physical  hardware  buss  structure,  the 
operating  system  and  read  only  memory  (ROM).  The  hardware  buss  that  IBM  se- 
lected on  which  to  base  thier  PC's  equipment  architecture  was  not  compatible  with 
the  S-100  buss,  the  industry  standard.  This  means  that  the  physical  connections  are 
different  from  previous  hardware  implementations.  These  buss  differences  account 
for  most  of  the  hardware  incompatibility  while  the  ROM  is  to  blame  [Ref.  14:  p.  48] 
for  the  rest.  The  ROM  is  called  in  order  to  access  many  of  the  hardware  features 
required  to  accomplish  interfacing  between  the  software,  the  operating  system  and 
the  microcomputer. 

Even  a  relatively  simple  application  like  word  processing  requires  cursor 
movements  and  delete  functions  which  must  be  accessed  by  the  ROM.  If  a  program 
goes  to  a  memory  location  expecting  to  find  an  instruction  and  finds  nothing  or, 
even  worse,  a  piece  of  data,  it  will  not  be  able  to  execute  the  correct  instruction.  This 
will  cause  the  program  to  stop.  Even  more  complicated  kinds  of  interface  problems 
arise  when  performing  graphics  functions  because  so  much  interaction  is  required 
between  screen  instructions,    memory  storage  and  system  functions  to  produce  screen 


images. 


The  actual  image  displayed  is  a  product  of  the  series  of  mapped  or  drawn  lines 
of  dots.      Each  dot  is  drawn  (turned  on  or  off)  on  the  screen.      The  number  of  dots 
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available  to  turn  on  or  off  per  inch  are  the  picture  elements  (referred  to  as  a  'pixels') 
and  the  higher  the  number  of  pixels,  the  higher  the  resolution  of  the  graphics.  The 
number  of  screen  pixels  addressable  are  characteristically  between  640  X  200  and  640 
X  400,  horizontally  and  vertically,  respectively.  All  the  different  pixel  combi- 
nations and  sizes  require  different  aspect  ratio  (height  to  width)  calculations  in  order 
to  correctly  represent  graphic  images.  Beyond  these  complications,  within  each  system 
there  are  graphics  modes  (e.g.  low,  medium  high,  etc.)  which  correspond  to  different 
resolutions.  Different  microcomputer  systems  store  the  data  and  information  required 
to  describe  the  picture  in  different  memory  locations,  which  adds  yet  one  more  level 
of  confusion.  From  this  brief  description  of  some  of  the  variables,  it  can  be  seen  that 
trying  to  write  one  software  program,  especially  a  graphics  intensive  one,  which 
would  apply  to  all  microcomputers  is  an  impossible  task. 

3.  Z- 100  Screen 

In  the  normal  text  mode,  the  Z-100  will  display  25  lines  of  text  at  80  characters 
per  line.  Each  character  is  comprised  of  a  matrix  of  8  X  9  pixels.  A  quick  and  simple 
calculation  leads  to  the  screen  resolution  of  640  (horizontal)  X  225  (vertical)  dots  which 
can  be  turned  on  or  off  to  draw  a  picture.  Although  too  complicated  to  address  in 
great  detail  in  this  thesis,  there  is  a  process  by  which  the  display  circuitry  in  the  Z-100 
can  address  the  pixels  to  provide  a  picture  400  lines  across,  instead  of  225.  This 
process  is  called  interlacing  because  every  other  line  is  displayed  in  an  alternating 
fashion.  The  price  payed  for  this  extra  resolution  is  a  flicker  apparent  to  the  human 
eye  in  this  mode.  Normally  the  screen  is  refreshed,  or  drawn  over,  60  times  every 
second.15  In  the  interlace  mode,  the  alternating  portions  of  the  screen  are  refreshed 
only  30  times  a  second,  which  can  be  seen  by  the  naked  eye.  This  gives  the  appearance 
of  "flickering". 

4.  Tektronix  Screen 

The  interlace  mode  would  provide  a  much  better  quality  (higher  resolution) 
representation  of  the  actual  graphics  quality  if  using  that  mode  when  emulating  a 
Tektronix  graphics  terminal.  The  Tektronix  screen  format  is  a  1024  X  1024  pixel  in- 
struction set,  but  the  rectangular  shape  of  the  cathode  ray  tube  (CRT)  reduces  the 
visual  area  to  a  1024  X  780  pixel  size.  There  are  other  differences  between  the  lo- 
cation  scheme   for   pixels    on   the  Tektronix   and  the  Z-100.     Figure  6  below  shows 


15  The  60  times  a  second  is  a  result  of  the  supply  power  of  60  Hz  (60  cycles  per  second). 
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there  is  also   a  difference  in  the  orientation  of  the  screen's  home  or  (zero,zero)  starting 
point. 

The   CRT  graphics  can  be  routed  (saved)  to  a  disk  file  or  sent  directly  to  a  dot 
matrix  printer  [Ref.  14:  p.  73]  and  printed  with  nearly   the    same  resolution  as  the  ori- 
ginal   picture.  16  The  real  advantage  of  this  will  become  apparent  in  the  next  section 
about  the  printer  programs  . 
5.     Emulation  Program 

There  are  a  number  of  factors  which  must  be  discussed  in  order  to  attack 
the  problem  of  creating  a  program  which  would  display  graphic  information  on 
microcomputers.  The  major  factors  to  be  considered  are  the  language  to  use  in  program 
development,  the  type  of  data  used  to  describe/create  the  drawings,  the  format  and 
contents  of  the  picture  data  file,  and  the  actual  drawing  program  itself.  Each  of  these 
areas  is  further  examined  below. 

a.  Language  Selection 

The  advantage  of  using  a  high  level  and  more  structured  programming 
language  than  BASIC  is  that  it  would  perhaps  provide  an  easier  avenue  to  approach 
the  actual  program  coding.  But  built-in  graphics  statements  are  only  available  in  the 
PC-DOS  version  of  PASCAL,  and  there  are  only  a  few  libraries  of  graphics  subroutines 
available  for  C  which  are  only  for  the  IBM  [Ref.  15:  p.  71].  BASIC,  on  the  other  hand, 
is  an  old  and  reliable,  if  not  omnipresent,  language  that  is  available  on  almost  all  gov- 
ernment- owned  machines.  Using  BASIC'S  built-in  graphics  statements  will  ensure  the 
program  will  run  on  all  of  the  target  microcomputers  and  can  be  easily  changed  as 
required  by  nearly  anyone  with  a  minimum  set  of  programming  skills. 

b.  Tektronix  Graphics  Protocol 

One  of  the  many  standard  graphics  formats  used  widely  is  the  Tektronix 
graphics  terminal  protocol.  The  high  performance  Tektronix  4010  series  terminals 
will  interface  with  many  host  graphics  processing  programs  such  as  SAS/GRAPH, 
TELL-A-GRAF,  GKS,  VANGO,  DI-3000,  PLOT-10,  DISSPLA  and  many  more. 
There  are  commercial  emulation  software  packages  available  for  the  IBM  PC  which 
emulate  all  the  capabilities  of  the  4010  terminal  except  those  that  depend  on  the  storage 


16  A  common  standard  dot  matrix  printer  like  the  OKIDATA  has  a  60  X  66  dot  per  inch 
printing  pattern.  When  printed  sideways  at  9.5"  x  6.5",  this  produces  an  area  print  of  627  X 
390  dots.  Recall  the  dot  per  inch  resolution  of  the  CRT  was  640  X  400  in  the  interleaving  mode. 
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Screen  Resolution  and  Orientation 
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Figure  6.      Differences  between  the  Tektronix  and  Z-100  CRT. 


tube  technology.  17  These  emulator  programs  are  relatively  inexpensive,  but  require 
a  specific  hardware  upgrade^  to  enhance  the  normal  IBM  graphics  capability  to  a 
higher  resolution  range,  which  brings  it  closer  to  the  normal  resolution  capa- 
bilities of  the  Z-100.    • 


17  The  storage  tube  technology  referred  to  are  the   write  thru  and  defocus  attributes  which 
are  activated  by   escape   sequence  instructions. 

18  The   hardware   upgrades   required  are   the    Color   Graphics  Adapter  (CGA),   Enhanced 
Graphics  Adapter  (EGA)  or  other  graphics  enhancing  computer  hardware  upgrade. 
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c.  Drawing  Program 

Utilizing  the  built-in  graphics  capabilities  of  the  Z-100,  the  graphing 
protocol  of  the  Tektronix  terminal  can  be  emulated  using  the  drawing  instruction 
statements  in  Z-BASIC.   The  approach  is  outlined  in  these  five  steps: 

1 .  Read  the  drawing  instruction  from  the  mainframe  or  other  other  graphics  source. 

2.  Calculate  the  equivalent  proportional  movement  on  the  Z-100  screen. 

3.  Draw  (turn  on  or  off)  each  vector  of  dot(s). 

4.  See  if  there  are  more  drawing  instructions  from  the  source  system. 

5.  Go  to  step  (1)  and  continue  until  finish  or  end  of  data  file. 

d.  Implementation 

The  emulator  program,  listed  in  Appendix  F  [Ref.  13:  p.  80]  was  adapted 
easily  for  use  with  the  DDN.  The  playback  program,  also  listed  in  Appendix  F  and 
suggested  in  the  same  article,  allows  any  picture  to  be  saved  to  a  disk  file  from  the  main 
emulator  program  and  to  be  redrawn  to  the  CRT.  The  program  code  itself  is  very 
well  documented  and  a  very  detailed  discussion  of  the  program  can  be  obtained  from 
the  original  article  if  further  information  is  required.  The  emulator  can  be  adapted  to 
nearly  any  system  easily  with  only  slight  variation. 

e.  Capabilities 

The  emulation  program  was  selected  because  it  includes  only  the  minimum 
set  of  capabilities  required  to  complete  the  task  of  emulating  a  tektronix  graphics  ter- 
minal. There  are  no  extras  to  cloud  the  major  emulation  issues  required  to  prove  the 
LO-CO-GRAF  system  concept.  The  basic  program  includes  a  communications  module 
which  allows  dialing  from  the  keyboard  if  using  an  auto  dial  modem.  The  graphics  data 
from  a  mainframe  processing  program  can  be  captured  (saved)  on  a  disk  on  the 
microcomputer  to  be  replayed/displayed  onto  the  Z-  100  CRT. 
/.     Picture  Data  File 

After  the  graphics  source  program  is  accessed,  any  picture  screen  can 
be  savedl9  to  a  disk  in  about  50  kilobytes  of  disk  storage  space,  which  leaves  enough 
room  for  the  emulator  program,  the  playback  program  and  six  picture  files  on  a  disk 
formatted  with  360  K  of  storage.  The  advantage  of  this  method  of  storage  is  that  play- 
ing back  the  picture  takes  a   very  short  time  because  it  fills  the  video  memory  with  the 


19  This  process  is  actually  reading  each  screen  memory  address  and  copying  each  byte  from 
memory  to   a  file  named  by  the  operator,  thus  creating  a  picture  data  iile. 
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data  and  does  not  have  to  redraw  the  picture  vector  by  vector.  With  the  picture  (e.g. 
map,  graph,  etc.)  redrawn  and  presented  on  the  CRT,  the  next  and  last  task,  of  the 
LO-CO-GRAF  process  is  producing  a  paper  copy  for  use. 

D.     SCREEN  PRINTING 

Paper  copies  of  maps,  charts,  and  other  graphics  may  never  be  replaced  by  other 
media.  With  all  the  computing  and  storage  power  available  today  there  is  still  a  reluc- 
tance to  do  away  with  the  "file"  or  "working"  copy.  The  LO-CO-GRAF  system  would 
not  be  complete  without  a  means  to  print  a  paper  copy   of  the  graphics  it  produces. 

Saving  the  frame20  by  capturing  the  video  memory  of  the  CRT  to  a  disk  file  is 
the  heart  of  the  playback  and  screen  printing  function.  Recall  (para  III.C.5.C.)  the  de- 
cision to  write  the  map  information  to  the  screen  and  then  save  it  as  a  pixel  by  pixel 
memory  dump.  This  process  maintains  the  best  possM0  -esolution  from  the  original 
vector  drawings  and  now  realizes  the  payoff  for  that  decision.  The  last,  and  now  easiest, 
task  for  the  system  is  to  simply  dump  the  screen  pixels  to  a  printer. 

There  are  many  screen  dump  programs  available  to  accomplish  this  but  the  one 
chosen  is  licensed  by  the  U.  S.  Government  and  applicable  to  many  standard  DOD 
printers. 

1.  SCDMP 

SCDMP  is  a  printing  utility  that  allows  reproduction  of  a  complete  video 
screen  on  a  dot  matrix  printer,  including  both  text  and  graphics,  without  having 
to  exit  the  current  program.  The  SCDMP  program  may  be  loaded  manually 
(by  entering  SCDMP  <cr>)  or  automatically,  via 'autoexec.bat',  into  memory  at  the 
beginning  of  a  session  where  it  remains  resident  until  needed.  To  print  a  desired  sta- 
tionary screen  or  frame,  simply  press  <SHIFT-F12>,  which  generates  an  interrupt-5 
and  activates  the  screen  dump. 

2.  Options 

The  SCDMP  program  allows  a  choice  of  which  color  bank  of  video  RAM  is 
dumped  (if  the  Z-100  has  all  banks  of  color  RAM  installed).  The  number  of 
video  RAM  (VRAM)  banks  installed  in  the  computer  is  determined  automatically 
by  SCDMP  upon  initial  load.  For  the  color  version,  entering  a  <B>  for  blue,  <R> 
for  red,  <  G  >  for  green,  or  <  A  >  for  all  banks  immediately  after  the 
<  SHIFT-F12>  will  select  the  VRAM  bank  to  be  printed.   If  no  character  is  entered, 


20  "Frame"  is  used  here  to  describe  the  graphic  and/or  alphanumeric  contents  of  the  CRT 
screen. 
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<  A  >  11  banks  is  the  default.  If  only  one  bank  of  color  RAM  is  installed,  only  the 
green  bank  can  be  dumped.  For  use  with  LO-CO-GRAF,  there  is  no  need  to  change 
from  the  default  since  only  the  green  bank  is  loaded  with  data  from  any  saved  map. 
SCDMP  also  allows  multiple  density  printing  for  some  printers.  Entering  an  <  H  > 
immediately  after  the  <SHIFT-F12>  or  color  selection  would  cause  the  printer  to 
use  a  higher  density  mode  for  printing.  The  default  density  is  normal  or  standard 
density.  The  higher  density  switch  will  make  the  printout  much  darker.  There  are 
several  other  useful  switch  options  which  are  explained  in  more  detail  in  the  SCDMP 
documentation. 21 

3.     Printer  Support 

The  printers  currently  supported  for  U.  S.  Government  use  are  the  Epson 
MX/RX/FX  Series  with  Graftrax,  the  Okidata  Microline  83A,  and  Zenith/MPI 
99/150  Series.  A  dot  matrix  printer  which  is  compatible  with  any  of  these  may  also 
be  used.  Only  the  printer  control  instructions  need  be  the  same.  The  control  sequence 
information  can  be  determined  from  the  printer  operating  manual  [Ref.  16].  Printing  a 
paper  copy  is  the  last  piece  of  the  LO-CO-GRAF  system.  The  next  step  is  to  put  it  all 
together  and  actually  create,  capture,  save,  playback,  and  print  a  map.  The  total  system 
will  be  evaluated  in  the  next  chapter  with  attention  given  to  any  problems  encountered. 


21  See  Appendix  G  for  specific  information. 
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IV.     ANALYSIS  OF  DATA 

This  chapter  investigates  the  actual  steps  required  to  obtain  maps  in  a  typical 
session  using  the  Defense  Data  Network  and  provides  an  analysis  of  the  graphics  pro- 
ducts produced  and  the  emulator  performance.  The  session  begins  with  accessing 
the  DDN  to  obtain  the  KERMIT  files  necessary  to  establish  a  viable  communi- 
cations network  and  ends  with  a  final  session  showing  how  to  use  that  network  to 
transmit  a  map  file. 

A.     OBTAIN  KERMIT 

The    best  way  to  show  how  the  system  works  is  to  use    it    to  promulgate    itself. 
Assuming  only  a  Knowledge  of  the  system  components  and  some  basic  skills  operating 
microcomputers   and   any   DDN      terminal      it   is   possible   to   see   the   power   of 
LO-CO-GRAF  inaction. 
1.    The  DDN  Session 

The  following  session  on  the  DDN  is  a  demonstration  of  how  to  obtain  the 
KERMIT  files  necessary  to  establish  a  working  communications  network  to  handle 
file  transfers  between  command  components  and  terminals.  The  first  step  is  to  locate 
a  DDN  terminal  and  sign  on  to  the  command's  account.  A  simple  File  Transfer  Pro- 
tocol (FTP)  to  the  Columbia  University  Center  for  Computing  will  facilitate  down 
loading  all  the  necessary  files  to  get  KERMIT.   The  session  follows: 

*  The    star  (*)  below  will  indicate  notes  to    the    operator    and  provide    details    not 
otherwise  available   The  <cr>  will  be  used  to  indicate  carriage  return. 

*  Sign  on  to  the  DDN  to  get  the  welcome  message: 

WELCOME  TO  DDN.    FOR  OFFICIAL  USE  ONLY.    TAC  LOGIN  REQUIRED. 

CALL  NIC   1-800-235-3155   FOR  HELP. 

MONTRY  TAC      113  #:  61 

(§0  3/103 

TAC  Userid:  XXXXX-XXXXX  *  Site  Specific 

Access  Code:  XXXXXX  *  Site  Specific 

Login  OK 

TCP  Trying. .  .  Open 

ISI-SYSTEM-A,  TOPS-20  Monitor  6.1(4050) 

There  are  31+15  jobs  and  the  Load  Average  is   2.  20 
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THIS   SYSTEM   IS  RESTRICTED  TO  UNCLASSIFIED   INFORMATION  ONLY. 
THE  ENTRY  OR  COMMUNICATION  OF  CLASSIFIED  DATA   IS   PROHIBITED. 

After   login,    type   "HELP   ?"    followed  by  a  carriage   return  for 
a   list  of  on-line  help  topics. 


*  After  login  enter  the  following: 
@FTP  CU20B.C0LUMBIA.EDU 

*  The  system  responds  with: 

Connection  opened  (Assuming  TYPE   L  36,    MODE   S,    STRU  P) 

<  CU20B.COLUMBIA.EDU  FTP   Server  Process   5Z(46)-7 
at  Fri   15-Jan-83    12: 28-EST 

CU20B. COLUMBIA.  EDU> 

*  Enter: 

LOGIN  ANONYMOUS  <cr> 

*  The  system  will  request  a  password: 
Password: 

*  Enter  GUEST  <cr>  and  the  response  follows: 

<  User  ANONYMOUS   logged  in  at  Fri   15-Jan-88   12:  28-EST,    job  207. 
CU20B. COLUMBIA.  EDU> 

*  At  this  point  request  access  to  the  KERMIT  disks  : 
CD  PK:<KERMIT>  <cr> 

*  The  response  will  be: 

<  Default  name  accepted.    Send  password  to  connect  to   it. 
CU20B.  COLUMBIA.  EDU> 

*  Now  enter  DIR  <  cr>  to  see  the  list  of  files  (it  is  very  long) 
DIR  <cr> 

<  List  started. 
PK: <KERMIT> 
AAAREAD. ME. 6 
AAAUPD.  HLP.  5 


AANETW. HLP. 29   *This  file  is  included  as  Appendix  D 

XXU.  C.2 

CU20B.  COLUMBIA.  EDU> 

*  At  this  point  just  follow  the  instructions  in  appendix  C  and  D  to  obtain  the  correct 
files  and  KERMIT  is  now  in  your  DDN  account  for  the  Heath/Zenith  Z-100. 

*  to   quit   and   get  back  to    your   home   terminal   is    standard  procedure  from  here: 
Enter  BYE  <cr>: 
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BYE  <cr> 

<  QUIT  command  received.  Goodbye. 

FTP>QUIT 

@LOGOUT 

Killed  Job  39,  User  BISHOPR,  TTY  162,  at  15-Jan-88  12:33:46 

Used  0:  00:  08  in  0:  07:  54 
Host  closing  connection 
Closed 

2.     KERMIT  in  Hand 

With  a  usable  copy  of  KERMIT  on  site,  one  can  set  up  a  communications 
network  between  any  other  computer  that  has  a  copy  of  KERMIT.  As  can  be  seen  by 
the  simple  session  above,  there  are  virtually  no  problems  associated  with  obtaining  the 
necessary  files  and  the  program  itself  is  self  documenting.  The  KERMIT  program  pro- 
vides virtually  error  free  transmission  for  data  files  and  other  programs  between  com- 
puters. 

The  KERMIT  program  is  the  central  pivot  for  sending  not  only  the  map  data 
files  but  for  the  terminal  emulator,  play  back  and  printing  programs  which  make  up 
the  LO-CO-GRAF  system. 

B.     TERMINAL  EMULATOR 

Invoking  the  terminal  emulator  requires  entering  the  program  name  if  a  compiled 
version  is  available.  If  not,  then  an  interpreted  version  may  be  used  but  will  run  a  little 
slower.  To  invoke  an  uncompiled  version,  enter  Z-BASIC  and  then  the  program  name. 
After  loading  the  emulator  it  is  necessary  to  access  a  source  program  for  generating 
the  graphics  products.  For  this  portion  the  DDN  was  again  chosen.  Using  the  Briefing 
Aid  System  (BAS)  on  the  DDN  as  the  remote  source  provided  an  excellent  example 
of  the  networking  capability  of  the  LO-CO-GRAF  system. 

A  working  session  will  demonstrate  how  to  access  the  graphics  generating 
program  but  first  it  is  necessary  to  put  an  instruction  file  in  the  DDN  directory  which 
identifies  the  type  of  terminal  used.22  Enter  and  name  a  file  that  will  reside  in  the  di- 
rectory to  provide  connection  instructions  for  the  backend  device  protocol  in  the 
BAS.    This  file  name  will   be  requested  during  the  graphics  session.    The  data  must 

be  entered  as  follows: 

backend=(tektronix) ,device=(d,tty: ) 

i 

After  the  file  is  created  on  the  DDN  and  put  in  the  directory,  the  BAS  program  files 
can  be  used. 


22  Appendix  H  provides  specific  instruction  for  accessing  the  DDN  with  a  Z-I00  and  then 
using  the  LO-CO-GRAF  system. 
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TEKTRONIX  4006/4010  GRAPHICS  TERMINAL  EMULATOR 
BAUD  :   1200   PARITY  :   N   BITS   :   8 


1SAVE  2FUTURE  3FUTURE  4CLS  5QUIT  6FUTURE  7CTRL-C  8X0FF   9X0N 


Figure  7.   Emulator  Screen 


•s> 


1.  Emulator  Screen  Size 

After  accessing  the  DDN,  set  the  terminal  screen  size  to  24  lines  long.  This 
will  keep  it  from  killing  the  program  and  dumping  out  of  the  emulator  back  to  the  op- 
erating system  on  the  Z-100.  The  problem  seems  to  stem  from  filling  the  screen  with 
data  or  alphanumerics  and  running  out  of  space.  When  running  the  emulator  this 
problem  can  be  avoided  by  clearing  the  screen  before  any  major  new  operation.  A 
preset  function  key  (F-4)  is  programmed  to  do  this  easily. 

2.  Emulator  Session 

After  invoking  the  emulator,  the  sign  on  the  screen,  as  shown  in  Figure  7,  ap- 
pears.   Clear  the  screen   before  continuing  and  enter  the  correct  codes  to  dial  the  DDN 

and  sign  on.    This  works  very  well  with  an  auto-  dial  modem  by  entering: 
ATDTXXXXXXX  *The  phone  number  varies  with  location 

The  next   step  was  to  access  the  program  in  the  following  manner: 


*  Again  signing  on  to  the  DDN 

WELCOME  TO  DDN.    FOR  OFFICIAL  USE  ONLY.    TAC   LOGIN  REQUIRED. 
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*  After  complete  login  enter: 
@DIR<LEVEL2> 

PS:  <LEVEL2> 
2400-SLIDE.GPX.  1 


AIRROUTES.  GPX. 1     *  This   slide   is   provided  as   example 


ETHIOPIAN-CONFLICT. GPX. 1     *  Some  of  these   slides    are  provided 

FALKLAND- ISLANDS.  GPX.  1         *  in  appendix  H 

HORMUZ.  GPX.  1 

MEDIT.  GPX.  1 

PACKET-RADIO-SLIDE.  GPX.  6 

RHORMUZ.  GPX.  1 

*  Above  is  a  list  of  maps  available  to  be  downloaded  from  the  BAS  in  the  level2  direc- 
tory.  To  download  one  just  enter: 
<level2>Viewer  <cr> 

The  main  menu  will  appear  and  ask  for  the  name  of  the  device  instruction 
file23  and  then  which  map  to  generate.  An  example  of  the  AIRROUTES. GPX  map 
is  in  Figure  8.  As  can  be  seen,  there  is  no  way  to  distinguish  between  the  two  colors 
that  indicate  the  two  routes.  This  is  not  a  problem  with  most  maps  because  a  single 
color  is  usually  all  that  is  available.  The  quality  is  comparable  to  a  similar  map 
generated  on  the  NPS  IBM  mainframe  computer  using  DISSPLA's  World  Coast  Utili- 
ties option. 

C.     MAP  QUALITY 

The  resolution  of  maps  currently  being  produced  electronically  is  sufficient  for  small 
scale,  large  area  planning.  These  maps  remain  highly  dependent  on  the  number  of  data 
points  available  for  generating  the  cartographic  projection.  Figures  9  and  10  represent 
typical  products  of  mainframe  resident  mapping  programs.  The  differences  are  partially 
due  to  printer  capability;  Figure  9  being  produced  on  an  Epson-based  dot  matrix,  while 
Figure  10  was  done  on  IBM  3800  laser  printer  capable  of  270  dpi.  These  maps  are  could 
be  ideal  for  strategic  and  operational  levels  of  command  and  staff  planning. 


23  This  is  the  file  placed  in  the  DDN  directory  above. 
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Figure  8.      Example  AIROUTES.GPX  Map 

1.     LO-CO-GRAF  and  Briefing  Aid  System  maps 

There  were  many  maps  to  choose  from  for  this  test  and  some  of  them  are  in 
Appendix  I  along  with  a  comparative  set  of  maps  generated  on  the  NTS  mainframe, 
which  are  included  at  Appendix  J.  The  maps  that  are  filled  in,  like  those  in  Figures  13 
through  15,  require  a  very  long  time  to  draw;  averaging  approximately  30  minutes  each. 
The  long  time  is  required  because  each    line    vector    must    be  calculated    and    drawn 
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Figure  9.      Map  generated  by  Briefing  Aid  System/DDN:    Area  map  of  the  North 
Sea  region. 

seperately  to  fill  in  an  area.  Although  this  time  is  relatively  long,  it  is  not  an  unac- 
ceptable period.  When  the  maps  were  saved  to  disk  and  played  back  later,  it  did  not 
make  a  difference  in  redraw  times  whether  they  were  filled  in  or  not.  The  redraw  times 
were  very  fast,  three  to  six  seconds. 
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Figure  10.      Map  generated  by  DISSPL A  World  Coast  Utilities:    Area  map  of  the 


North  Sea  and  English  Channel  region. 


2.     DISSPLA  maps 

The  typical  map  generation  times  for  DISSPLA  was  seventy  seconds.  The  time 
for  a  metafile  to  generate  a  map  from  its  stored  data  was  thirty  seconds,  but  was  more 
dependent  on  system  loading.  The  longest  recall  time  for  a  metafile  was  210  seconds  in 
a  program  where  DISSPLA  used  many  of  its  self-correcting  features.    The  maps  would 
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be  suitable  for  strategic  and  operational  level  planners,  however  possible  tactical  uses 
are  negligible.  The  metafiles  transport  via  any  file  transfer  protocol  and  the  DISSPOP 
option  of  DISSPLA  can  display  them  on  an  extremely  wide  selection  of  graphics  devices. 
The  times  required  to  generate  these  maps  were  acceptable.  Better  cartographic  resol- 
ution created  by  a  greater  number  of  data  points  could  increase  the  times  for  map  gen- 
eration, but  this  probably  would  also  be  in  the  acceptable  range. 
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V.     CONCLUSIONS  AND  RECOMMENDATIONS 

The  premise  of  this  thesis  is  that:  (1)  access  to  maps  via  electronic  means  is  cur- 
rently feasible  and  desirable,  and  (2)  combining  a  standard  dot  matrix  printer  with  the 
Z-100  microcomputer  (purchased  en  masse  between  1982  and  1986)  and  developing  a 
few  software  programs  which  could  provide  a  low  cost  graphics  and  map  generating  ca- 
pability which  would  greatly  enhance  the  command  and  control  process.  These  premises 
were  achieved. 

A.     VALIDATION 

The  goal  of  this  thesis,  to  show  that  the  Zenith  Z-100  will  emulate  a  Tektronix 
graphics  terminal,  has  been  validated.  The  specific  C2  objective  of  electronically  trans- 
ferring maps  and  charts  has  also  been  achieved.  Another  command  and  control  tool  has 
been  developed  which  can  be  further  exploited. 

1.  Large  Screen  Displays 

The  current  cartographic  representations  used  in  situation  rooms  and  command 
centers  for  their  large  screen  displays  lack  resolution.  The  preliminary  steps  have  been 
taken  in  this  thesis  to  make  maps  and  charts  available  at  the  desk  of  every  microcom- 
puter user  requiring  them.  The  benefits  are  significant  to  the  commander  and  decision 
makers,  intelligence,  logistics,  and  communications  personnel.  With  the  addition  of 
more  resources  and  research  to  microcomputer  graphics  emulation,  operationally  ori- 
ented personnel  and  tactical  levels  of  command  will  soon  benefit  equally.  An  example 
of  this  is  the  current  maps  used  in  WWMCCS  displays  and  in  command  centers  which 
use  other  strategic  and  operational  level  cartographic  tools. 

2.  Simplicity 

A  self-imposed  requirement  to  attain  this  command  and  control  tool  at  no  cost 
has  been  achieved.  This  constraint  was  levied  in  order  to  make  it  accessible  to  all  DOD 
commands  as  soon  as  possible.  The  no-cost  alternative  for  having  a  local  graphics  ter- 
minal capability  is  highly  desirable.  Many  commands  which  have  placed  their  Z-100's 
on  shelves,  in  storage,  or  marked  for  disposal  could  reconsider  that  decision.  The  variety 
of  graphics  products  which  can  be  displayed,  sent,  or  received  is  very  significant  and  will 
become  more  important  to  the  C2  process  in  the  future.  The  no-cost  decision  also  lim- 
ited the  number  of  options  that  could  be  considered  to  software  already  purchased  by 
the  DOD  or  in  the  public  domain. 
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B.     RECOMMENDATIONS  FOR  FUTURE  EFFORTS 

The  scope  of  this  project  was  sufficient  to  occupy  the  available  time.  It  did,  how- 
ever, surface  many  future  areas  of  endeavor  to  be  expanded.  Below  are  listed  a  few  of 
the  interest  areas  uncovered: 

1.  User  Friendly 

The  requirement  to  be  more  user  friendly  will  surface  continuously  until  the 
machines  are  as  smart  as  people  are  and  will  do  what  is  required  without  being  told. 
Specific  areas  which  could  use  more  smoothing  are:  (1)  Map  generating  packages  on 
mainframe  computers  operating  interactively,  requiring  only  page  or  screen  dimensions, 
level  of  resolution,  and  location  and  scale  of  the  map  or  chart,  and  (2)  the  graphics  ter- 
minal emulator,  though  designed  to  be  friendly,  should  not  intimidate  the  user.  Selection 
of  devices  and  capabilities  should  be  menu  driven  and  include  error  and  fault  checking. 

2.  Applications  to  Tactical  Users/  C2  Centers 

Access  to  tactical  level  maps  and  charts  remains  the  real  requirement.  The  only 
centralized  source  of  this  cartographic  information  continues  to  be  DMA  and  NOAA. 
Therefore,  DMA  or  NOAA  must  devise  a  system  for  accessing  their  digitized  mapping 
databases  and  allowing  the  users  to  custom  build  their  own  maps  and  charts.  A  possible 
approach  to  solving  the  shortcoming  of  not  having  the  ability  to  transfer  maps  and 
charts  electronically,  would  be  to  develop  programs  for  many  microcomputers  to  con- 
struct and  display  the  cartographic  plots.  The  microcomputer  would  need  to  have  a 
graphics  capability  sufficient  for  this  type  of  display.  The  example  of  maps  or  charts 
required  for  a  command  and  control  center  is  given  above.  A  more  significant  require- 
ment is  the  ability  to  pass  tactical  level  maps.  Many  units  will  have  ready  brigades, 
specific  ships,  or  air  squadrons  in  an  alert  status.  When  these  units  are  required  to 
"fly-away",  they  possibly  may  not  have  gotten  to  the  point  on  the  logistics  checklist  for 
tactical  maps.  The  necessary  graphics  products  could  be  prepared  for  the  unit  and 
transmitted  to  it  while  in  transit.  Similarly,  intelligence  updates  and  other  information 
could  be  transmitted  as  soon  as  available. 

3.  NPS  Applications 

The  Naval  Postgraduate  School's  academic  program  has  many  uses  for 
cartographic  products.  For  example,  the  National  Security  Affairs  Department  uses 
some  of  the  microcomputer's  map  generation  programs  discussed  in  Chapter  I.  These 
are  used  for  strategic  level  discussions  and  as  aids  in  geographic  analysis.  The  Admin- 
istrative Sciences  Department  uses  similar  products  to  allow  graphical  analysis  of  sta- 
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tistical  data.  The  Meteorology  and  the  Air-Ocean  Science  Department  commonly  use 
the  map  generation  program  maintained  on  the  DEC  mainframe  computers  at  Fleet 
Numerical  and  Oceanographic  Center  across  the  highway.  The  biggest  user  of  maps  and 
charts  would  probably  be  the  Operations  Research  Department,  specifically  the 
Wargaming  and  Analysis  Laboratory.  Their  current  system  uses  video  disc  technology 
to  display  maps  in  the  Joint  Theater  Level  System  (JTLS)  and  low  resolution  digitized 
maps  for  Naval  Warfare  Integrated  Simulation  System/ Integrated  Battle  Group  Tactical 
Trainer  (NWISS/IBGTT). 

a.  Specific  Uses  for  DISSPLA  Maps 

One  suggested  area  for  further  study  is  the  generation  of  flat  earth  maps  to 
use  in  battle  planning  or  deployment  exercises.  These  maps  could  be  bounded  and 
sized  in  a  standard  way,  by  latitude  and  longitude,  so  that  they  could  be  cut  and 
pasted  to  expand  as  operational  maneuvers  move  from  one  map  section  to  another. 
This  would  be  especially  useful  to  those  who  must  respond  to  crisis  situations  world 
wide  but  who  have  limited  knowledge  of  world  geography  or  no  access  to  existing 
maps. 

b.  Increased  use  of DISS  POP 

The  ability  to  save  graphics  in  a  compressed  version,  a  metafile,  is  very  sig- 
nificant. Preparation  by  students  or  instructors  could  be  made  readily  available  and  with 
little  specialized  training.  More  output  device  options  would  need  to  be  added  to  the 
current  DISSPOP  selection.  Examples  of  these  could  include  IBM  PC's  with  CGA, 
EGA,  or  Hercules  upgrades  added  in.  Most  home  computers  with  a  significant  graphics 
capability  could  also  be  included. 

c.  NPS  War  Lab 

A  desirable  output  of  this  thesis  was  to  make  the  map  generation  program; 
and  the  Z-100  graphics  terminal  emulator,  portable  so  they  could  be  transferred  into  the 
Wargaming  Laboratory.  The  communications  package  and  screen  dump  routines  would 
also  have  to  be  customized  to  equipment  existing  in  the  laboratory.  This  portion  was 
not  attempted  due  to  lack  of  time.  Significant  equipment  differences  exist  between  the 
wargaming  laboratory  and  the  main  computer  center  which  would  require  reworking  of 
all  phases  of  this  project.  A  partial  listing  of  the  necessary  changes  follows: 

1.  The  computer  center  uses  an  IBM  mainframe,  the  War  Lab  uses  a  VAX  computer. 

2.  DISSPLA  with  the  map  generation  option  is  maintained  on-line  with  the  computer 
center.  The  War  Lab  requires  that  advance  notice  be  provided  so  DISSPLA,  and 
the  necessary  operating  environment  for  it,  can  be  scheduled. 
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3.  The  map  generation  programs  and  its  interactive  version  are  written  in  VS  Fortran 
which  is  IBM  exclusive.  The  programs  would  need  to  be  modified  so  they  are 
compatible  with  Fortran  77  in  the  VAX  environment. 

4.  A  different  version  of  the  communications  program  (KERMIT)  would  need  to  be 
employed.  As  the  discussion  in  Chapter  III  indicates,  the  version  of  KERMIT  to 
talk  between  a  VAX  and  almost  any  microcomputer  is  available.  The  protocols 
remain  the  same,  which  is  the  reason  KERMIT,  in  particular,  was  chosen  for  use 
in  this  project. 

5.  The  screen  dump  program  chosen  for  this  project  was  designed  with  most  of  the 
industry  standard  printer  protocols  available.  The  correct  version  would  need  to 
be  chosen  for  the  printers  connected  to  the  Z-100's  in  the  War  Lab. 

d.     DOD  distributed  wargaming  system 

A  future  addition  to  the  NPS  War  Lab  is  a  connection  to  the  DOD  Dis- 
tributed Network  (DISNET)  subnet  for  C3  research.  This  system  will  serve  NPS  and 
four  other  research  and  development  centers  and  engineering  activities.  Gateways  to 
other  classified  and  unclassified  capabilities  on  the  DDN  would  have  to  be  identified. 
The  opportunity  exists  with  this  system  to  have  available  more  expertise  and,  probably, 
a  greater  desire  to  access  high  resolution  digitized  maps  and  charts  or,  if  desired,  to  de- 
velop tactical  ones  for  specific  circumstances.  The  use  of  electronically  transmitted  maps 
could  prove  to  be  valuable  research  in  the  C3  wargaming  and  evaluation  networks. 
Research  conducted  to  aid  the  command  decision  maker  by  overlayed  maps  or  maps 
with  imbedded  symbology  could  also  be  conducted. 
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APPENDIX  A.     EXAMPLE  PROGRAM  SHOWING  DISSPLA'S 
INTERACTIVE  MAPPING  CAPABILITY 

The  following  Fortran  program  uses  DISSPLA's  map  generation  option.  It  has 
been  written  to  be  user  friendly  and  "sailor-proof.  The  program  needs  to  be  performed 
at  a  graphics  workstation  which  includes  a  TEK  618.  In  order  to  run  this  program  on 
different  equipment,  some  modification  would  be  necessary. 

A.  HOW  TO  RUN  THE  DISSPLA  MAP  GENERATOR 

After  you  have  copied  the  following  program  you  can  generate  any  of  the  listed 
maps  at  any  time  you  wish: 

NOTE:  You  must  be  using  an  MPS  terminal   that  has  a  Tektronics  618 
graphics  monitor  attached . 

1.  Enter    "DISSPLA"    The  program  will  respond  with  a  welcome  message. 

2.  When  the  program  requests  the  name  of  the  program  you  wish  to  run,  enter  the 
file  name  you  have  given  this  program  and  then  press  "PF- 10/22"  to  execute. 
There  are  other  options  at  this  point  for  help  (PF- 1/1 3),  to  quit  (PF-  3/15),  or 
to  view  or  edit  a  map  file  (PF-4/16). 

3.  After  pressing  the  PF- 10/22  key  (execute)  you  will  see  several  messages,  in- 
dicating compiler  passes,  flash  across  the  screen.  This  will  be  followed  by  a  mes- 
sage indicating  what  file  deffinitions  are  in  effect  and  asking  you  if  you  would  like 
to  execute  the  program  with  those  deffinitions  or  exit.  After  DISSPLA  calls 
up  all  the  supporting  programs,  you  will  be  asked  to  press  the  enter  key  to 
continue.   This  step  loads  the  Fortran  program  to  be  executed  and  compiles  it. 

4.  The  program  has  been  written  to  guide  you  through  the  selection  of  a  map  to 
plot  and  plot  it  for  you.  You  will  then  be  asked  to  enter  the  name  of  the  map  you 
have  chosen.  As  the  data  for  the  map  is  called  from  disk  storage  you  will  see 
the  plot  being  generated  on  the  TEK-618.  After  the  map  is  plotted  on  the 
graphics  monitor,  you  will  receive  a  prompt  on  the  IBM  terminal  monitor  in- 
structing you  to  press  "enter"  to  continue.  If  you  want  a  hard  copy  of  the  map,  you 
can  press  the  HARD  COPY  button  on  the  bottom  of  the  graphics  monitor  first. 

B.  INTERACTIVE  MAP  GENERATION  FORTRAN  PROGRAM 

C^rtWrVr^*:^**^**^**'^:^  MAP  0  0  0 1 0 

C*  "THE  POWER  OF  DISSPLA's  MAP  PROJECTION  OPTION"  *  MAP00030 

C*  *  MAP00040 

C*  BRETTE  WALKER  *  MAP00050 

C*  GENE  BISHOP  *  MAP00060 

C*  ROB  SABO  *  MAP00070 

Q*4HHr*4Hr*nlMnlr4nl^^  MAP  Q  0  0  8  0 
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c 

c 

INITIALIZE 

INTEGER  CHOICE, 

ANSWER 

CHOICE  =  0 

ANSWER  =  0 

c 

c 

MENU 

10 

20 

25 

30 

40 
50 
60 
70 
80 
90 
92 
100 


WRITE  (6.10) 

FORMAT  (f  THIS  PROGRAM  DEMONSTRATES  THE  MAP  GENERATION  ',/ 
1'  CAPABILITY  OPTION  OF  THE  DISSPLA  PROGRAM.  ') 

WRITE  (6  20) 

FORMAT  (r  CERTAIN  MAPS  HAVE  BEEN  PREPROGRAMMED  INTO  THIS  ',/ 
1'  DEMONSTRATION  AND  ARE  AVAILABLE  FOR  YOUR  VIEWING  ONLY  ',/ 
2'  ON  THE  TEK618  DISPLAY. ' ) 

WRITE  (6,30) 

FORMAT  ( '  PLEASE  SELECT  FROM  THE  MENU  BELOW  THE  EXAMPLE  MAP  ' , / 
1 '  YOU  WOULD  LIKE  TO  VIEW.  ' ) 

WRITE  (6,40) 

MENU') 


FORMAT  (' 

WRITE  (6,50) 

FORMAT  (   1. 

WRITE  (6.60) 

FORMAT  (  f  2. 

WRITE  (6,70) 

FORMAT  ('  3. 

WRITE  (6,80) 

FORMAT  ('  4. 

WRITE  (6,90) 

FORMAT  ( '  5. 

WRITE  (6  92) 

FORMAT  ('  6. 

WRITE  (6.100) 

FORMAT  (f  PLEASE  ENTER  YOUR  CHOICE: 

READ  *, CHOICE 


NORTH  AND  SOUTH  AMERICA.  ' ) 
CARIBBEAN  AREA.  ' ) 
NORTHERN  FLANK.  ' ) 
MEDITERRANEAN  AREA.  ' ) 
JAPAN  AREA.  * ) 
QUIT.  * ) 


1,2,3,4,5  OR  6. ') 


C  ERROR  CHECK  OF  CHOICE 
C 

C  IF  THE  CHOICE  IS  ONE  OF  THE  ALLOWABLE  CHOICES  THEN  CONTINUE 
IF  (CHOICE.  GT.O.  AND.  CHOICE.  LT.  7)  GO  TO  110 

C  ELSE  IF  AN  ERRONEOUS  CHOICE  THEN  REENTER  CORRECT  CHOICE 

WRITE  (6,105) 
105   FORMAT  ( '  YOU  HAVE  MADE  AN  INCORRECT  ENTRY.  ' ) 

GO  TO  25 
C 

C  CONTINUE 
110   IF  (CHOICE.  EQ.  1)  CALL  NSAMER 

IF  (CHOICE. EQ. 2)  CALL  CARMAP 

IF  (CHOICE. EQ.  3)  CALL  NORMAP 

IF  (CHOICE. EQ. 4)  CALL  MEDMAP 

IF  (CHOICE. EQ. 5)  CALL  JAPMAP 

IF  (CHOICE. EQ. 6)  GO  TO  145 
C 
C  TRY  AGAIN? 

WRITE  (6,120) 
120   FORMAT  ( '  WOULD  YOU  LIKE  TO  TRY  AGAIN? ' ) 


MAPOOIOC 

MAP0011C 

MAP0012C 

MAP0013C 

MAP0014C 

MAP0015C 

MAP0016C 

MAPOOUCI 

MAP0018CI 

MAP0019C 

MAP0020C 

MAP0021C 

MAP0022C 

MAP  00  230 

MAP0024t 

MAPOO250: 

MAPOO260 

MAP0027C 

MAP0028C 

MAP0029C 

MAPOO30C 

MAPOO310 

MAP0032C 

MAP0033C 

MAPOO340 

MAP0035C 

MAP0036C 

MAPOO370 

MAPOO380 

MAP0039C 

MAPOO4O0 

MAPOO410 

MAPOO420 

MAPOO430 

MAPOO440 

MAPOO450 

MAP0046C 

MAPOO470 

MAP0048C 

MAPOO490 

MAPOO5O0 

MAPOO510 

MAPOO520 

MAPOO530 

MAP0054C 

MAP0055C 

MAPOO560 

MAPOO570 

MAPOO580 

MAPOO590 

MAPOO6O0 

MAPOO610 

MAPOO620 

MAPOO630 

MAPOO640 

MAPOO650 
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125   WRITE  (6.130) 

130   FORMAT  ( f  ENTER  1  FOR  YES  OR  2  FOR  NO.  ' ) 

READ  *, ANSWER 
C 
C  CHECKING  INPUT  FOR  ERROR 

IF  (ANSWER.  GT.  0.  AND.  ANSWER.  LT.  3)  GO  TO  140 

WRITE  (6,135) 
135   FORMAT  ( '  YOU  HAVE  MADE  AN  INCORRECT  ENTRY.  ' ) 

GO  TO  125 
C 

C  CONTINUE  BY  CHECKING  FOR  YES  OR  NO 
C 

C  CHECK  FOR  YES 

140   IF  (ANSWER.  EQ.  1)  GO  TO  25 
C 

C  ELSE  ANSWER  IS  NO  AND  PROGRAM  IS  EXITED 
145   WRITE  (6.150) 
150   FORMAT  ( i   HAVE  A  NICE  DAY.  ' ) 

STOP 

END 


C 
C 
C 

c 

c 
c 
c 


c 
c 
c 
c 


SUBROUTINE  FOR  MAP  OF  NORTH  h   SOUTH  AMERICA 

THIS  SUBROUTINE  WILL  CREATE  A  MAP  OF  NORTH  &  SOUTH  AMERICA  INCLUDING 

CENTRAL  AMERICA,  HAWAII,  AND  THE  CARRIBEAN 

SUBROUTINE  NSAMER 
LEVEL  0 

CALL  GRAPHICS  DEVICE 

CALL  TEK618 

CALL  HWSCAL  ('SCREEN') 


LEVEL  1 


SET  PAGE  SIZE  AND  PROJECTION  SPECIFICATIONS 


C 
C 
C 
C 

C 
C 

c 
c 

c 
c 
c 


A=ll 

CALL  PAGE  (A, 8. 5) 
CALL  PROJCT  ('MERCA') 
CALL  MAPOLE  (-120,  0.  ) 
CALL  AREA2D  (10,8) 

LEVEL  2 

DEFINE  MAP  PARAMETERS 

CALL  MAPGR  (-180.  ,30.  ,10.  ,-55.  ,30.  ,75.  ) 

LEVEL  3 

CALLS  FOR  CARTOGRAPHIC  DATA  AND  LEVEL  OF  RESOLUTION 

CALL  MAPEIL  ( *  COAS  * ) 

RETURN  TO  LEVEL  2 

CALL  ENDPL(O) 

RETURN 


MAP00660 
MAP00670 
MAP00680 
MAP00690 
MAP00700 
MAP00710 
MAP00720 
MAP00730 
MAP00740 
MAP00750 
MAP00760 
MAP00770 
MAP00780 
MAP00790 
MAP00800 
MAP00810 
MAP00820 
MAP00830 
MAP00840 
MAP00850 
MAP00880 
MAP00890 
MAP00900 
MAP00910 
MAP00920 
MAP00930 
MAP00940 
MAP00950 
MAP00960 
MAP00970 
MAP00980 
MAP00990 
MAP01000 
MAP01010 
MAP0102C 
MAP01030 
MAP01040 
MAP01050 
MAP01060 
MAP01070 
MAP01080 
MAP01090 
MAP01100 
MAP01110 
MAP01120 
MAP01130 
MAP01140 
MAP01150 
MAP01160 
MAP01170 
MAP01180 
MAP01190 
MAP01200 
MAP01210 
MAP01220 
MAP01230 
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c 
c 
c 
c 
c 
c 
c 
c 
c 

c 
c 
c 
c 


c 

c 
c 

G 

c 
c 
c 
c 


c 
c 
c 


END 

SUBROUTINE  NORMAP 

THIS  IS  THE  NORTHERN  FLANK  OF  NATO 

THIS  PROGRAM  WILL  GENERATE  A  THEATER  LEVEL  MAP  OF  THE  NORTHERN 
FLANK  AND  INCLUDES  ALL  THE  SCANDINAVIAN  COUNTRIES. 

LEVEL  0 

CALL  GRAPHICS  DEVICE 

CALL  TEK618 

LEVEL  1 

SET  PAGE  SIZE  AND  PROJECTION  SPECIFICATIONS 

CALL  PAGE(15.  ,11.  ) 

CALL  SCMPLX 

CALL  PROJCT('MERCA') 

CALL  MAPMDE('STRAI') 

CALL  AREA2D(13.  ,9.  ) 

CALL  XNAME('  '  ,1) 

CALL  YNAMEC  *  ,1) 

CALL  XAXANG(0.  ) 

CALL  HE AD IN( ' NORTHERN  FLANK  OF  NATO" ,22, 1.  5, 1) 

LEVEL  2 

DEFINE  MAP  PARAMETERS 

CALL  MAPGR(-15.  ,5.  ,55.  ,55.  ,5.  ,75.  ) 

LEVEL  3 

CALLS  FOR  CARTOGRAPHIC  DATA  AND  LEVEL  OF  RESOLUTION 

CALL  MAPFIL('PEUR') 
CALL  MAPFIL('EURO') 
CALL  MAPFIL('ASIA') 
CALL  MAPFIL('PASI') 
CALL  FRAME 
CALL  DASH 
CALL  GRID(1,1) 
CALL  MARKER(-l) 

RETURN  TO  LEVEL  2 

CALL  ENDPL(O) 

RETURN 
END 

SUBROUTINE  JAPMAP 
THIS  IS  A  MAP  OF  THE  OPERATING  AREAS  AROUND  JAPAN 

THIS  PROGRAM  WILL  GENERATE  A  THEATER  LEVEL  MAP  OF  THE  SEA  OF 

JAPAN. 


48 


c 
c 
c 
c 

c 
c 
c 
c 


c 

c 
c 

G 

c 
c 
c 

c 


c 
c 
c 


c- 

c 
c 
c 
c 
c 
c 

c 
c 
c 
c 


LEVEL  0 

CALL  GRAPHICS  DEVICE 

CALL  TEK618 

LEVEL  1 

SET  PAGE  SIZE  AND  PROJECTION  SPECIFICATIONS 

CALL  PAGE(15.  ,11.  ) 

CALL  SCMPLX 

CALL  PROJCTCMERCA') 

CALL  MAPMEE('STRAI') 

CALL  AREA2D(13.  ,9.  ) 

CALL  XNAME('  '  ,1) 

CALL  YNAMEC  '  ,1) 

CALL  XAXANG(0.  ) 

CALL  HEADINC* JAPAN  AND  THE  KURILE  ISLANDS' ,28, 1.  5, 1) 

LEVEL  2 

DEFINE  MAP  PARAMETERS 

CALL  MAPGR(125.  ,5.  ,160.  ,30.  ,5.  ,55.  ) 

LEVEL  3 

CALLS  FOR  CARTOGRAPHIC  DATA  AND  LEVEL  OF  RESOLUTION 

CALL  MAPFIL('ASIA') 
CALL  MAPFIL('PASI') 
CALL  FRAME 
CALL  DASH 
CALL  GRID(1,1) 
CALL  MARKER(-l) 

RETURN  TO  LEVEL  2 

CALL  ENDPL(O) 

RETURN 
END 

SUBROUTINE  MEDMAP 

THIS  PROGRAM  WILL  GENERATE  A  THEATER  LEVEL  MAP  OF  THE 
MEDITERRANEAN  SEA. 

LEVEL  0 

CALL  GRAPHICS  DEVICE 

CALL  TEK618 

LEVEL  1 

SET  PAGE  SIZE  AND  PROJECTION  SPECIFICATIONS 


CALL  PAGE(15.  ,11.  ) 

CALL  SCMPLX 

CALL  PROJCT('MERCA') 


MAP01840 

MAP01850 

MAP01860 

MAP01370 

MAP01880 

MAP01890 

MAP01900 

MAP01910 

MAP01920 

MAP01930 

MAP01940 

MAP01950 

MAP01960 

MAP019  70 

MAP01980 

MAP01990 

MAP02000 

MAP02010 

MAP02020 

MAP02030 

MAP02040 

MAP02050 

MAP02060 

MAP02070 

MAP02080 

MAP02090 

MAP02100 

MAP02110 

MAP02120 

MAP02130 

MAP02140 

MAP02150 

MAP02160 

MAP02170 

MAP0218-, 

MAP02190 

MAP02200 

MAP02210 

MAP02220 

MAP02230 

MAP02260 

MAP02270 

MAP02280 

MAP02290 

MAP02300 

MAP02340 

MAP02350 

MAP02360 

MAP02370 

MAP02380 

MAP02390 

MAP02400 

MAP02410 

MAP02420 

MAP02430 

MAP02440 
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c 

c 
c 
c 

c 

c 

C 

c 


c 
c 
c 


CALL  MAPMDEC ' STRAI ' ) 

CALL  AREA2D(13.  ,9.  ) 

CALL  XNAMEC  '  ,1) 

CALL  YNAMEC  '  ,1) 

CALL  XAXANG(0.  ) 

CALL  HEAD IN(' MEDITERRANEAN  SEA' ,17,1. 5,1) 

LEVEL  2 

DEFINE  MAP  PARAMETERS 

CALL  MAPGR(-10.  ,5.  ,40.  ,25.  ,5.  ,50.  ) 

LEVEL  3 

CALLS  FOR  CARTOGRAPHIC  DATA  AND  LEVEL  OF  RESOLUTION 

CALL  MAPFIL('PEUR') 
CALL  MAPFIL('EURO') 
CALL  MAPFIL('ASIA') 
CALL  MAPFIL('PASI') 
CALL  MAPFIL('PAFR') 
CALL  MAPFIL('AFRI') 
CALL  FRAME 
CALL  DASH 
CALL  GRID(1,1) 
CALL  MARKER(-l) 

RETURN  TO  LEVEL  2 

CALL  ENDPL(O) 

RETURN 
END 


C 
C 

c 
c 
c 
c 
c 
c 
c 

c 
c 

c 
c 


SUBROUTINE  CARMAP 

THIS  IS  A  MAP  OF  THE  CARRIBEAN  OPERATING  AREAS 

THIS  PROGRAM  WILL  GENERATE  A  THEATER  LEVEL  MAP  OF  THE  CARIBBEAN 
SEA  AND  THE  GULF  OF  MEXICO.  ALL  OF  CENTRAL  AMERICA  IS  INCLUDED. 

LEVEL  0 

CALL  GRAPHICS  DEVICE 

CALL  TEK618 

LEVEL  1 

SET  PAGE  SIZE  AND  PROJECTION  SPECIFICATIONS 

CALL  PAGE(15.  ,11.  ) 
CALL  SCMPLX 
CALL  PROJCT('MERCA') 
CALL  MAPMDEC' STRAI') 
CALL  AREA2D(13.  ,9.  ) 
CALL  XNAME( *  ' ,1) 
CALL  YNAME( '  '  ,1) 
CALL  XAXANGCO.  ) 


MAP024i 

MAP  024* 

MAP024", 

MAP024* 

MAP024S 

MAP025C 

MAP025] 

MAP025S 

MAP025: 

MAP025* 

MAP025! 

MAP0256 

MAP025/ 

MAP025* 

MAP025S 

MAP026C 

MAP026] 

MAP0262 

MAP0262 

MAP0264 

MAP0265 

MAP0266 

MAP0267 

MAP0268 

MAP0269 

MAPO270 

MAP0271 

MAP0272 

MAP0273 

MAP0274 

MAP0275 

MAP0276 

MAP0280 

MAP0281 

MAP0282 

MAP0283 

MAP0284 

MAP0285 

MAP0286 

MAP0287 

MAP0288 

MAP0289 

MAP0290 

MAP0291 

MAP0292 

MAP0293 

MAP0294 

MAP0295 

MAP0296 

MAP0297 

MAP0298 

MAP0299 

MAP0300 

MAP0301 

MAP0302 

MAP0303 
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c 

c 

G 
C 

C 
C 
C 
C 


C 

c 
c 


CALL  HEADIN(" CARIBBEAN  SEA' , 13, 1.  5 , 1) 

LEVEL  2 

DEFINE  MAP  PARAMETERS 

CALL  MAPGRC-100. ,5. ,-60. ,5. ,5. ,35. ) 

LEVEL  3 

CALLS  FOR  CARTOGRAPHIC  DATA  AND  LEVEL  OF  RESOLUTION 

CALL  MAPFIL('PNOR') 
CALL  MAPFIL('NORT') 
CALL  MAPFIL('PSOU') 
CALL  MAPFIL('SOUT') 
CALL  FRAME 
CALL  DASH 
CALL  GRID(1,1) 
CALL  MARKER(-l) 

RETURN  TO  LEVEL  2 

CALL  ENDPL(O) 

RETURN   . 
END 


MAP03040 
MAP03050 
MAP03060 
MAP03070 
MAP03080 
MAP03090 
MAP03100 
MAP03110 
MAP03120 
MAP03130 
MAP03140 
MAP03150 
MAP03160 
MAP03170 
MAP03180 
MAP03190 
MAP03200 
MAP03210 
MAP03220 
MAP03230 
MAP03240 
MAP03250 
MAP03260 
MAP03270 
MAP03280 
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APPENDIX  B.     DISSPLA  MAP  GENERATION  PROGRAMS 

The  following  Fortran  programs  can  be  used  by  DISSPLA  to  generate  maps.  Some 
modification  could  be  necessary  in  order  to  ensure  compatibility  to  the  mainframe  and 
graphics  terminals  they  would  be  run  on.  As  written,  they  were  developed  using  VS 
Fortran.  The  version  of  DISSPLA  being  used  must  include  the  World  Coast  Utilities 
Option  and  the  DISSPOP  option  which  causes  compression  and  decompression  of  the 
map  files.  Table  2  lists  the  maps  that  can  be  generated  by  the  VS  Fortran/ DISSPLA 
programs  and  the  pages  they  can  be  found  on. 


Table  2.     GUIDE  TO  DISSPLA  MAPPING  PROGRAMS 

Map  description 

Page 

Carribean  Operating  Area 

53 

Northern  Flank  of  NATO 

54 

North  and  South  America 

55 

Washington,  DC 

56 

World  Mercator  Projection 

57 

Cape  Canaveral/ Kennedy  Space  Center 

59 

Japan  and  the  Kurile  Islands 

60 

Mediterranean  Operating  Area 

61 

North- West  Europe 

62 

52 


c 
c 
c 
c 
c 

C 

c 
c 

c 
c 
c 
c 


c 
c 
c 
c 

c 
c 
c 
c 


c 
c 
c 


THIS  IS  A  MAP  OF  THE  CARRIBEAN  OPERATING  AREAS 

THIS  PROGRAM  WILL  GENERATE  A  THEATER  LEVEL  MAP  OF  THE  CARIBBEAN 
SEA  AND  THE  GULF  OF  MEXICO.  ALL  OF  CENTRAL  AMERICA  IS  INCLUDED. 

LEVEL  0 

CALL  GRAPHICS  DEVICE 

CALL  COMPRS 

LEVEL  1 

SET  PAGE  SIZE  AND  PROJECTION  SPECIFICATIONS 

CALL  PAGE(15.  ,11.  ) 

CALL  SCMPLX 

CALL  PROJCT('MERCA') 

CALL  MAPMDE('STRAI') 

CALL  AREA2D(13.  ,9.  ) 

CALL  XNAMEC  '  ,1) 

CALL  YNAMEC  '  ,1) 

CALL  XAXANG(0.  ) 

CALL  HEADIN( ' CARIBBEAN  SEA' , 13,1.  5, 1) 

LEVEL  2 

DEFINE  MAP  PARAMETERS 

CALL  MAPGRC-IOO.  ,5.  ,-60.  ,5.  ,5.  ,35.  ) 

LEVEL  3 

CALLS  FOR  CARTOGRAPHIC  DATA  AND  LEVEL  OF  RESOLUTION 

CALL  MAPFIL('PNOR') 
CALL  MAPFIL('NORT') 
CALL  MAPFIL('PSOU') 
CALL  MAPFIL('SOUT') 
CALL  FRAME 
CALL  DASH 
CALL  GRID(1,1) 
CALL  MARKER(-l) 

RETURN  TO  LEVELS  2 ,  1 , . AND  0 

CALL  ENDPL(O) 
CALL  DONEPL 
STOP 
END 


CAR00030 
CAR00040 
CAR00050 
CAR00060 
CAR00070 
CAR00080 
CAR00090 
CAR00100 
CAR00110 
CAR00120 
CAR00130 
CAR00140 
CAR00150 
CAR00160 
CAR00170 
CAR00180 
CAR00190 
CAR00200 
CAR00210 
CAR00220 
CAR00230 
CAR00240 
CAR00250 
CAR00260 
CAR00270 
CAR00280 
CAR00290 
CAR00300 
CAR00310 
CAR00320 
CaR00330 
CAR00340 
CAR00350 
CAR00360 
CAR00370 
CAR00380 
CAR00390 
CAR00400 
CAR00410 
CAR00420 
CAR00430 
CAR00440 
CARO 0A50 
CAR004G0 
CAR00470 
CAR00480 
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c 

C 
C 
C 
C 
G 
C 

c 

c 
c 
c 

c 


c 
c 
c 
c 

c 
c 
c 
c 


c 
c 
c 


THIS  IS  THE  NORTHERN  FLANK  OF  NATO 

THIS  PROGRAM  WILL  GENERATE  A  THEATER  LEVEL  MAP  OF  THE  NORTHERN 
FLANK  AND  INCLUDES  ALL  THE  SCANDINAVIAN  COUNTRIES. 

LEVEL  0 

CALL  GRAPHICS  DEVICE 

CALL  COMPRS 

LEVEL  1 

SET  PAGE  SIZE  AND  PROJECTION  SPECIFICATIONS 

CALL  PAGE(15.  ,11.  ) 

CALL  SCMPLX 

CALL  PROJCT('MERCA') 

CALL  MAPMDE('STRAI*) 

CALL  AREA2D(13.  ,9.  ) 

CALL  XNAMEC  ',1) 

CALL  YNAMEC"  ' ,1) 

CALL  XAXANG(0.  ) 

CALL  HE AD IN(' NORTHERN  FLANK  OF  NATO' ,22, 1.  5 , 1) 

LEVEL  2 

DEFINE  MAP  PARAMETERS 

CALL  MAPGR(-15.  ,5.  ,55.  ,55.  ,5.  ,75.  ) 

LEVEL  3 

CALLS  FOR  CARTOGRAPHIC  DATA  AND  LEVEL  OF  RESOLUTION 

CALL  MAPFIL('PEUR') 
CALL  MAPFILCEURO') 
CALL  MAPFIL('ASIA') 
CALL  MAPFIL('PASI') 
CALL  FRAME 
CALL  DASH 
CALL  GRID(1,1) 
CALL  MARKER(-l) 

RETURN  TO  LEVELS  2,  1,  AND  0 

CALL  ENDPL(O) 
CALL  DONEPL 
STOP 
END 
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c 

G 
C 
C 
C 
C 


C 
C 

c 
c 


THIS  PROGRAM  WILL  CREATE  A  MAP  OF  NORTH  &  SOUTH  AMERICA  INCLUDING 
CENTRAL  AMERICA,  HAWAII,  AND  THE  CARRIBEAN 


C 

c 
c 
c 

c 
c 
c 
c 

c 

c 
c 

c 
c 
c 

c 
c 
c 


LEVEL  0 


CALL  GRAPHICS  DEVICE 


CALL  COMPRS 

CALL  HWSCAL  ( *  SCREEN' ) 


LEVEL  1 


SET  PAGE  SIZE  AND  PROJECTION  SPECIFICATIONS 


A=ll 

CALL  PAGE  (A, 8. 5) 
CALL  PROJCT  ('MERCA') 
CALL  MAPOLE  (-120,  0. ) 
CALL  AREA2D  (10,8) 

LEVEL  2 

DEFINE  MAP  PARAMETERS 

CALL  MAPGR  (-180.  ,30.  ,10.  ,-55.  ,30.  ,75.  ) 

LEVEL  3 

CALLS  FOR  CARTOGRAPHIC  DATA  AND  LEVEL  OF  RESOLUTION 

CALL  MAPFIL  ( ' CO AS ' ) 
RETURN  TO  LEVEL  2 

CALL  ENDPL(O) 
RETURN  TO  LEVEL  1 

CALL  DONEPL 

RETURN  TO  LEVEL  0 

STOP 
END 


NSA00010 
NSA00020 
NSA00030 
NSA00040 
NSA00050 
NSA00060 
NSA00070 
NSA00080 
NSA00090 
NSA00100 
NSA00110 
NSA00120 
NSA00130 
NSA00140 
NSA00150 
NSA00160 
NSA00170 
NSA00180 
NSA00190 
NSA00200 
NSA00210 
NSA00220 
NSA00230 
NSA00240 
NSA00250 
NSA00260 
NSA00270 
NSA00280 
NSA00290 
NSA00300 
NSA00310 
NSA00320 
NSA00330 
NSA00340 
NSA00350 
NSA00360 
NSA00370 
NSA00380 
NSA00390 
NSA00400 
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c 
c 
c 
c 
c 
c 
c 
c 

c 
c 
c 
c 


c 
c 
c 
c 

c 
c 
c 
c 


c 

c 
c 

c 
c 

c 

c 
c 


THIS  IS  A  MAP  GENERATED  TO  COMPARE  RESOLUTION  BETWEEN  DISSPLA 
GENERATED  MAPS  AND  OTHER  DIGITIZED  MAPPING  PROGRAMS. 

THIS  IS  A  MAP  OF  THE  WASHINGTON  DC  AREA 

LEVEL  0 

CALL  GRAPHICS  DEVICE 

CALL  COMPRS 

LEVEL  1 

SET  PAGE  SIZE  AND  PROJECTION  SPECIFICATIONS 

CALL  PAGE(8.  5,11.  ) 

CALL  SCMPLX 

CALL  PROJCT('MERCA') 

CALL  MAPMDE('STRAI') 

CALL  AREA2D(6.  ,8.  ) 

CALL  XNAMEC  '  ,1) 

CALL  YNAMEC  '  ,1) 

CALL  XAXANG(0. ) 

CALL  HEADIN( 'WASHINGTON  DC  AREA' , 18, 1.  5 , 1) 

LEVEL  2 

DEFINE  MAP  PARAMETERS 

CALL  MAPGR(-78.  ,0.5,-76.  ,38.  ,0.5,40.  ) 

LEVEL  3 

CALLS  FOR  CARTOGRAPHIC  DATA  AND  LEVEL  OF  RESOLUTION 

CALL  MAPFIL('PNOR') 
CALL  MAPFIL('NORT') 
CALL  MAPFIL('USAH') 
CALL  FRAME 
CALL  DASH 
CALL  GRID (1,1) 
CALL  MARKER(-l) 

RETURN  TO  LEVEL  2 

CALL  ENDPL(O) 

RETURN  TO  LEVEL  1 
CALL  DONEPL 

RETURN  TO  LEVEL  0 

STOP 

END 


56 


The  following  program  will  generate  a  world  map. 


G 
C 
C 
C 


C 
C 


DIMENSION  DAT(72,46),RHITE(72,46) 
COMMON  WORK(5000) 
CALL  COMPRS 

DO  10  N=12,72,12 
M=N-11 

READ(10,1000)  ((DAT(I,JJ),I=M,N),JJ=1,46) 
1000  FORMAT(F6.0,11F5.0) 

10  CONTINUE 

DO  11  J=2,45 
JP1=J+1 
JM1=J-1 
DO  11  1=1,72 
IP1=M0D(I,72) 
IMl=MOD(I+70,72)+l 
S=0.  90 

RHITE(I,J)=(1.  -S)*DAT(I,J)+(S/4.  )*(DAT(IM1,J)+DAT(IP1,J)+ 
*DAT(I,JP1)+DAT(I,JM1)) 

11  CONTINUE 

DO  12  1=1,72 
RHITE(I,1)=DAT(I,1) 

12  RHITE(I,46)=DAT(I,46) 

CALL  BLOWUP  (2.  2) 
CALL  BASALF  ('STAND') 
CALL  MIXALF  ('L/CSTD') 

CALL  PROJCT  ('AITOF') 

FOR  AITOFF  PROJECTION 
CALL  PAGE  (10.0,8.0) 

SET  PAGE  FOR  VIEWGRAF 
CALL  AREA2D  (8.5,4.0) 

CALL  XNAME  ('  ',1) 
CALL  YNAME  ('  ',1) 
CALL  SCMPLX 
48  CALL  HEADIN  ('THE  WORLD? * , 100, 1.  5, 1) 

99  CALL  YAXANG  (0.  ) 

CALL  MAPGR  (-300.  ,30.  ,60.  ,-90.  ,30.  ,90.  ) 

CALL  GRID  (1,1) 

CALL  MAPFIL  ('HERSHEY') 

CALL  FRAME 

CALL  HEIGHT(0.  05) 

CALL  COMPLX 

CALL  BCOMON(5000) 


WLD00010 
WLD00020 
WLD00030 
WLD00040 
WLD00050 
WLD00060 
WLD00070 
WLD00080 
WLD00090 
WLD00100 
WLD00110 
VLD00120 
WLD00130 
WLD00140 
WLD00150 
WLD00160 
WLD00170 
WLD00180 
WLD00190 
WLD00200 
WLD00210 
WLD00220 
WLD00230 
WLD00240 
WLD00250 
WLD00260 
WLD00270 
WLD002G0 
WLD00290 
WLD00300 
WLD00310 
WLD00320 
WLD00330 
WLD00340 
WLD00350 
WLD00360 
WLD00370 
WLD00380 
WLD00390 
WLD00400 
WLD00410 
WLD00420 
WLD00430 
WLD 00440 
WLD00450 
WLD00460 
WLD00470 
WLD00480 
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Fortran  program  WLDPLT  continued. 

CALL  C0NMAK(RHITE,72,46,'SCALE') 
CALL  C0NMAK(RHITE)72,46,'SCALE') 
C  PLOT  SMOOTHED  CONTOURS 

CALL  CONLIN  (0, ' SOLID' ,' LABELS' , 1,5) 
CALL  CONANG(90. ) 
CALL  RASPLN(0.  25) 
CALL  CONTUR( 1 , ' LABELS ' , *  DRAW ' ) 
CALL  COMPLX 
CALL  HEIGHT(.2) 

CALL  MESSAG('DISSPLA  MAP$' ,  100,3.  5  , -1.  ) 
CALL  RESET( ' COMPLX* ) 
CALL  RESET(* HEIGHT') 
CALL  ENDPL(O) 
CALL  DONEPL 
STOP 
END 
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c 

c 
c 
c 
c 
c 

G 
C 

c 

G 
C 

c 


c 
c 
c 
c 

c 

c 

G 
C 


c 

G 
C 

C 
C 

C 

c 
c 


THIS  IS  A  MAP  GENERATED  TO  COMPARE  RESOLUTION  BETWEEN  DISSPLA 
GENERATED  MAPS  AND  OTHER  DIGITIZED  MAPPING  PROGRAMS. 

THIS  IS  A  MAP  OF  THE  KENNEDY  SPACE  CENTER/ CAPE  CANAVERAL  AREA 

LEVEL  0 

CALL  GRAPHICS  DEVICE 

CALL  COMPRS 

LEVEL  1 

SET  PAGE  SIZE  AND  PROJECTION  SPECIFICATIONS 

CALL  PAGE(11.  ,8.5) 

CALL  SCMPLX 

CALL  PROJCTC'MERGA') 

CALL  MAPMDE('STRAI') 

CALL  AREA2D(8. ,6. ) 

CALL  XNAMEC  '  ,1) 

CALL  YNAMEC  '  ,1) 

CALL  XAXANG(0. ) 

CALL  HEADINC'CAPE  CANAVERAL  FLA' ,18,1.  5,1) 

LEVEL  2 

DEFINE  MAP  PARAMETERS 

CALL  MAPGR(-81.  ,0.5,-80.  ,28.  ,0.5,29.  ) 

LEVEL  3 

CALLS  FOR  CARTOGRAPHIC  DATA  AND  LEVEL  OF  RESOLUTION 

CALL  MAPFIL('PNOR') 
CALL  MAPFIL('NORT') 
CALL  MAPFIL('USAH') 
CALL  FRAME 
CALL  DASH 
CALL  GRID(1,1) 
CALL  MARKER(-l) 

RETURN  TO  LEVEL  2 

CALL  ENDPL(O) 

RETURN  TO  LEVEL  1 
CALL  DONEPL 

RETURN  TO  LEVEL  0 

STOP 
END 


EZM00010 
EZM00020 
EZM00030 
EZM00040 
EZM00050 
EZM00060 
EZM00070 
EZM00080 
EZM00090 
EZM00100 
EZM00110 
EZM00120 
EZM00130 
EZM00140 
EZM00150 
EZM00160 
EZM00170 
EZM00180 
EZM00190 
EZM00200 
EZM00210 
EZM00220 
EZM00230 
EZM00240 
EZM00250 
EZM00260 
EZM00270 
EZM00280 
EZM00290 
EZM00300 
EZM00310 
EZM00320 
EZM00330 
EZM00340 
EZM00350 
EZM00360 
EZM00370 
EZM00380 
EZM00390 
EZM00400 
EZM00410 
EZM00420 
EZM00430 
EZM00440 
EZM00450 
EZM00460 
EZM00470 
EZM00480 
EZM00490 
EZM00500 
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c 

c 
c 
c 
c 
c 
c 
c 

c 
c 

C 

c 


G 
C 
C 

c 
c 

G 
C 

c 


c 
c 
c 


THIS  IS  A  MAP  OF  THE  OPERATING  AREAS  AROUND  JAPAN 

THIS  PROGRAM  WILL  GENERATE  A  THEATER  LEVEL  MAP  OF  THE  SEA  OF 
JAPAN. 

LEVEL  0 

CALL  GRAPHICS  DEVICE 

CALL  COMPRS 

LEVEL  1 

SET  PAGE  SIZE  AND  PROJECTION  SPECIFICATIONS 

CALL  PAGE(8.  5,11.  ) 

CALL  SCMPLX 

CALL  PROJCT('MERCA') 

CALL  MAPMDE('STRAI') 

CALL  AREA2D(6.  ,8.  ) 

CALL  XNAME(*  ' ,1) 

CALL  YNAMEC  *  ,1) 

CALL  XAXANG(0.  ) 

CALL  HEADIN( ' JAPAN  AND  THE  KURILE  ISLANDS' ,28, 1.  5, 1) 

LEVEL  2 

DEFINE  MAP  PARAMETERS 

CALL  MAPGR(125.  ,5.  ,160.  ,30.  ,5.  ,55.  ) 

LEVEL  3 

CALLS  FOR  CARTOGRAPHIC  DATA  AND  LEVEL  OF  RESOLUTION 

CALL  MAPFIL('ASIA') 
CALL  MAPFIL('PASI') 
CALL  FRAME 
CALL  DASH 
CALL  GRID(1,1) 
CALL  MARKER(-l) 

RETURN  TO  LEVELS  2,  1,  AND  0 

CALL  ENDPL(O) 
CALL  DONEPL 
STOP 
END 
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c 

c 
c 
c 
c 

C 

c 
c 
c 
c 


c 
c 

c 
c 

c 
c 
c 
c 


c 
c 
c 


THIS  PROGRAM  WILL  GENERATE  A  THEATER  LEVEL  MAP  OF 
MEDITERRANEAN  SEA. 

LEVEL  0 

CALL  GRAPHICS  DEVICE 

CALL  COMPRS 

LEVEL  1 

SET  PAGE  SIZE  AND  PROJECTION  SPECIFICATIONS 

CALL  PAGE(15.  ,11.  ) 

CALL  SCMPLX 

CALL  PROJCT('MERCA') 

CALL  MAPMDE('STRAI') 

CALL  AREA2D(13. ,9. ) 

CALL  XNAMEC  '  ,1) 

CALL  YNAMEC  '  ,1) 

CALL  XAXANG(0. ) 

CALL  HEADINC MEDITERRANEAN  SEA1 ,17,1. 5,1) 

LEVEL  2 

DEFINE  MAP  PARAMETERS 

CALL  MAPGRC-IO.  ,5.  ,40.  ,25.  ,5.  ,50.  ) 

LEVEL  3 

CALLS  FOR  CARTOGRAPHIC  DATA  AND  LEVEL  OF  RESOLUTION 

CALL  MAPFIL('PEUR*) 
CALL  MAPFIL('EURO') 
CALL  MAPFIL('ASIA') 
CALL  MAPFIL('PASI') 
CALL  MAPFIL('PAFR') 
CALL  MAPFIL( ' AFRI ' ) 
CALL  FRAME 
CALL  DASH 
CALL  GRID(1,1) 
CALL  MARKER(-l) 

RETURN  TO  LEVELS  2,  1,  AND  0 


CALL  ENDPL(O) 
CALL  DONEPL 
STOP 
END 


MED00030 
MED00040 
MED00070 
MED00080 
MED00090 
MED00100 
MED00110 
MED00120 
MED00130 
MED00140 
MED00150 
MED00160 
MED00170 
MED00180 
MED00190 
MED00200 
MED00210 
MED00220 
MED00230 
MED00240 
MED00250 
MED00260 
MED00270 
MED00280 
MED00290 
MED00300 
MED00310 
MED00320 
MED00330 
MED00340 
MED00350 
MED00360 
MED00370 
MED00380 
MED00390 
MED00400 
MED00410 
MED00420 
MED00430 
MED00440 
MED00450 
MED00460 
MED00470 
MED00480 
MED00490 
MED00500 
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c 

c 
c 
c 
c 

c 
c 
c 
c 


c 
c 
c 
c 

c 
c 
c 
c 


c 
c 
c 


THIS  PROGRAM  WILL  GENERATE  A  THEATER  LEVEL  MAP  OF  NORTH-WEST  EUROPE 

LEVEL  0 

CALL  GRAPHICS  DEVICE 

CALL  COMPRS 

LEVEL  1 

SET  PAGE  SIZE  AND  PROJECTION  SPECIFICATIONS 

CALL  PAGE(8.  5,11.  ) 

CALL  SCMPLX 

CALL  PROJCT('MERCA') 

CALL  MAPMDE('STRAI') 

CALL  AREA2D(6.  ,8.  ) 

CALL  XNAMEC  *  ,1) 

CALL  YNAMEC  '  ,1) 

CALL  XAXANG(0. ) 

CALL  HEADIN( ' NORTH-WESTERN  EUROPE' ,20, 1.  5, 1) 

LEVEL  2 

DEFINE  MAP  PARAMETERS 

CALL  MAPGRC-10. ,5. ,15. ,45. ,5. ,62. ) 

LEVEL  3 

CALLS  FOR  CARTOGRAPHIC  DATA  AND  LEVEL  OF  RESOLUTION 

CALL  MAPFIL('PEUR') 
CALL  MAPFIL('EURO') 
CALL  FRAME 
CALL  DASH 
CALL  GRID (1,1) 
CALL  MARKER(-l) 

RETURN  TO  LEVELS  2,  1,  AND  0 

CALL  ENDPL(O) 
CALL  DONEPL 
STOP 
END 


UKM0( 

UKMOC 

UKMOC 

UKMOC 

UKMOC 

UKMOC 

UKMOC 

UKMOC 

UKMOC 

UKMOC 

UKMOC 

UKMOC 

UKMOC 

UKMOC 

UKMOC 

UKMOC 

UKMOC 

UKMOG 

UKMOG 

UKMOO 

UKMOQ 

UKMOO 

UKMOQ 

UKMOO 

UKMOO 

UKMOO 

UKMOO 

UKMOO 

UKMOO 

UKMOO 

UKMOO 

UKMOO 

UKMOO 

UKMOO 

UKMOO 

UKMOO 

UKMOO 

UKMOO 

UKMOO 

UKMOO 

UKMOO 


62 


APPENDIX  C.      KERMIT  ON-LINE  HELP  FILES 

This    is  a  printout  of  a  help  file  which  is  resident  on  the  Columbia  University  Computer. 
It  is  updated  about  once  a  year.    This  version  is  accurate  to  28  Jan  88. 


COLUMBIA  UNIVERSITY  KERMIT  DISTRIBUTION 

This  file  explains  what  files  are  in  the  Kermit  distribution  and  gives  the  naming 
conventions  for  them. 

If  you  are  reading  this  from  a  handout  supplied  with  a  Kermit  distribution  tape, 
please  note  that  this  information  might  not  be  quite  up  to  date  —  there  may  be  files  on 
the  tape  that  are  not  listed  here.  The  copy  of  this  file,  AAFILES.HLP,  on  the  tape 
might  be  more  current. 

The  file  AAFILx.DIR  contains  an  up-to-date  alphabetical  directory  listing  of 
all  the  files  in  the  respective  Kermit  distribution  area  (KER:,  Tape  A;  K2:,  Tape  B; 
K3:,  Tape  C;  etc.)  --  one  such  file  is  created  in  each  area  by  a  nightly  batch  job  (x  is 
A,  B,  C,  etc).  The  directory  listing  supplied  on  paper  with  your  tape  should  reflect 
exactly  which  files  are  on  the  tape,  and  in  what  order. 

The  Kermit  distribution  areas  include  all  the  versions  of  Kermit  which  are  in  our 
possession.    The  files  have  names  of  the  form 

NAME.TYPE 

where  NAME  is  the  name  of  file,  and  TYPE  is  its  type 

(program  source,   documentation,   executable  core  image, 

etc).     No  NAME   is  more  than  9  characters   long  (the 

maximum  accepted  by  VAX/ VMS),  and  every  NAME  starts  with 

a   letter  and  is  unique  in  the  first  6   characters  (the 

maximum  under  TOPS- 10,   RSTS/E,  etc).   On  TOPS- 10  BACKUP 
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Interchange  tapes,  names  longer  than  6  will  be  truncated 
to   6.    No  type  is  longer  than  3  characters.     NAME  and 
TYPE  are  separated  by  a  period. 

*  Types 

The  files  types  don't  follow  a  strict  convention  because  the  files  originate  on  so  many 
different  systems.  But  there  are  some  patterns;  here  are  some  commonly  used  file  types 

For  Text  Files: 

. BLD  -  Instructions  for  building 

. BWR  -  A  "beware"  file,  listing  known  bugs,  limitations, 

or  other  problems 
. DIF   -  Differences  (produced  by  file   comparison 

program) 
.DOC  -  Documentation  (usually  long) 
. HLP  -  Help  message  (like  DOC  but  usually  shorter) 
. INS  -  Installation  instructions 
. MAN  -  A  manual 

.MEM  -  Documentation  ("memo")  produced  by  DEC  Runoff 
.  MSG  -  A  text  or  mail  message  of  some  kind 
. MSS  -  Scribe  text  formatter  source  (for  some  of  the 

.DOC  files) 
. NR  -  Nrof f  text  formatter  source 
. RNH  -  Runoff  text  formatter  source  for  .HLP  files 
. RNO  -  Runoff  text  formatter  source  for  . MEM  files 
.TEX  -  TeX  source 
.TXT  -  Text  (usually  shorter,   sometimes  in  electronic 

mail  message  format) 
. UPD  -  Program  update  history 
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For  Program  Source: 

.A  -  Assembler 

.A68  -  Algol-68 

.A86  -  8086  assembler 

.ADA  -  Ada 

.ALG  -  Algol-60 

. ASM  -  Assembler 

. B  -  B  language 

. BAS  -  Basic 

. BLI  -  Bliss 

.BOO  -  "boo"  format  printable  encoding  of  object  or  executable  program 

.  G  -  C  language 

.  CLU  -  CLU  language 

.F  -  Fortran  (Unix) 

.F77  -  Fortran-77 

.FOR  -  Fortran 

.FTN  -  Fortran 

. H  -  Header  file  for  G  or  ASM  program 

. H86  -  8086  hexadecimal  encoding  of  object  or  executable  program 

.HEX  -  Hexadecimal  encoding  of  object  or  executable  program 

. HQX  -  "binhex"  encoding  of  object  or  executable  program 

. LSP  -  Lisp  source  code 

.MAC  -  Macro  assembler 

.MAR  -  VAX  assembler 

. PAS  -  Pascal 

. PL1  -  PL/ I 
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For  Program  Source  Ccon'O: 

.PLC  -  PL/C 

.PLI  -  PL/ I 

.  PLM  -  PL/M 

.REQ  -  VAX  "require"  (header)  file 

. SAI  -  Sail 

. SCR  -  A  FORTH  "screen" 

. SRC  -  Source  program 

For  Svstem  or  Command  Files: 

.BAT  -  A  batch  control  file  (e.g.  for  MS-DOS) 

.  CMD  -  A  command  file  of  some  kind 

.COM  -  VAX  or  PDP-11  DCL  command  file 

.  CTL  -  A  batch  control  file  (e.g.  for  DEC-10/20) 

. INI  -  Initialization  command  file 

.  JCL  -  Job  control  language  (e.g.  for  Harris) 

*  Prefixed  File  Names: 

The  file  names  for  files  associated  with  each  implementation  of  Kermit  are  prefixed 
by  a  few  characters  denoting  the  implementation.  Although  the  files  are  kept  in 
separate  areas,  each  prefix  is  unique  among  all  the  Kermit  files,  so  that  areas  can  be 
combined  into  a  single  area  without  any  confusion.  The  following  are  presently  used, 
(Items  marked  with  asterisk  have  fuller  explanations  below): 


66 


'-"micros"    (tape  A)    -- 


Prefix    Machine(s) 

Operating  System 

Language 

APP 

Apple  II 

DOS  3. 3  or  ProDos 

6502  Asm 

AST 

Atari  ST  Series 

GEM 

C 

ATA 

Atari  Home  Computer 

DOS 

Action! 

C64 

Commodore  64 

DOS 

CROSS 

*C86 

8086/8088  (see  below) 

CP/M-86 

ASM86 

CC 

TRS-80  Color  Computer 

Disk-Extended  Color  ] 

BASIC  EDTASM 

*CP4 

8080,8085, Z80(see  beL 

aw)  CP/M-80 

LASM 

*CPM 

8080, 8085, Z80  --  obso 

lete,  see  below  -- 

cx 

Experimental  new  release  of  CP/M-80  Kermit 

LASM 

K6 

0S9/68000  Portable 

various 

Assembler 

M4 

TRS-80  Model  4 

TRSDOS 

ASM 

*MS 

Various  (see  below) 

MS-DOS  or  PC-DOS 

MASM 

QK 

(various,  see  below) 

Turbo  Pascal 

TA2 

Tandy  2000 

MS  DOS 

MASM 

TRS 

TRS-80  I  and  III 

TRSDOS 

Z80  Ass. 

TR2 

TRS-80  Model  II 

TRSDOS 

Z80  Ass. 

WIN 

IBM  PC,  etc 

MS-DOS  w/MS -Windows 

Microsoft  C4. 0 

WK 

IBM  PC  family 

PC  DOS 

Lattice  C 

See  below  for  notes  about  MS-DOS  and  CP/M  Kermits. 
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--"mainframes"    (Tape  B1    -- 


Prefix    Machine(s) 

Operating 

System 

Language 

*CK 

VAX,  SUN,  many  others 

UNIX 

C 

*CK 

VAX 

VMS 

C 

*CK 

Apple  Macintosh 

Mac  OS 

C 

*CK 

Commodore  Amiga 

AmigaDOS/ Intuition    C 

*CK 

Data  General  MV  Series 

AOS/VS 

C 

*CK 

Apollo 

Aegis 

C 

CM2 

IBM  370  Series 

VM/CMS 

Pascal/VS 

IK 

IBM  370  Series 

VM/CMS 

IBM  Ass. 

K10 

DECsystem-10 

TOPS -10 

MACRO- 10 

*K11 

DEC  PDP-11 

RSX11,RSTS/E, 

RT11, 

TSX  MACRO- 11 

*K11 

DEC  PDP-11 

P/OS,  Pro 

/RT, 

IAS 

3. 1  MACR0-11 

K20 

DECSYSTEM-20 

TOPS-20 

MACRO -20 

MP 

DEC  PDP-11 

MUMPS  (M/ll) 

MUMPS 

*TSO 

IBM  370-series/3705 

MVS/TSO 

Assembler 

*TS2 

IBM  370-series/Seriesl 

MVS/TSO 

Pascal/VS, PL/I 

,  etc 

*TS3 

IBM  370-series/3708 

MVS/TSO 

Assembler 

*TSN 

IBM  370-series/3705 

MVS/TSO 

Ass. /ALP 

UX 

Old,  old,  small  Unix  Kermit 

C 

*VMS 

VAX 

VMS 

Bliss-32 

*  C-Kermit  (Prefix  CK,  Tape  B): 

C- Kermit  is  a  transportable  version  of  Kermit  written  in  the  C  language.  It  is 
composed  of  many  modules,  some  system-  independent,  some  system- specific.  C- 
Kermit  has  been  implemented  on  many  systems,  some  "mainframes"  and  some 
"micros".  In  particular,  the  Unix  version  runs  on  machines  ranging  from  large  IBM 
mainframes  to  VAX  and  other  minicomputers  to  small  PC's,  and  Kermit  programs  for 
the  Apple  Macintosh,  the  Commodore  Amiga,  VAX/VMS,  DG  AOS/VS,  Apollo 
Aegis,  CDC  VX/VE,  and  many  other  systems  can  also  be  generated  from  C-Kermit. 
All  the   C-Kermit  source   files  are  kept  together  on  tape  B  to  avoid   the   problems  that 
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would  be  introduced  by  splitting  up  the  files   or  keeping  duplicate  copies.     See  the  file 
CKAAAA.HLP  for  an  explanation  of  the  file  naming  conventions  for  C-Kermit. 

*  The  Kll  files  include  support  for  RSX,  RSTS,  RT11,  TSX  +  ,  IAS, 

and  P/OS  --  See   K11INS.DOC  for  details. 

*  The  VAX/VMS  Bliss  version  is  also  provided  in  MACRO-32  (.MAR) 

source  form  for  those  sites  that  do  not  have  a  Bliss 

compiler,  as  well  as  in  a  hexadecimal  encoding  of  the  task 

image.   YOU  DON'T  NEED  TO  HAVE  BLISS  IN  ORDER  TO  RUN  THIS 

VERSION.   See  VMSAAA.HLP. 

*  Among  the  TSO  Kermits,  you  should  probably  try  the  TSN  version 

first.  The  TSO  versions  (one  for  linemode,  a  separate  one 
for  Series/ 1 -style  3270   emulation)  are  very  old  and 
primitive.   The  Pascal  version  requires  a  Pascal  compiler 
and  supports  only  linemode  connections.   The  TSN  version, 
from  NIH,  supports  only  linemode  connections,  but  includes 
many  advanced  features.   There's  also  version  with  the 
prefix  TS3,  which  supports  the  3708  front  end.   Many  of 
these  will  be  replaced  by  "portable  370"  Kermit  soon,  under 
prefix  IKO  and  IKT. 

For  VM/CMS,  please  try  the  new  IK*.*  version.  This  is  "portable  370"  Kermit, 
which  is  a  very  advanced  Kermit  implementation,  to  which  support  for  other  IBM  370 
operating  systems,  like  MVS/TSO,  DOS/VSE,  MTS,  MUSIC,  etc,  should  be  easy  to  add. 
It  supports  most  of  the  advanced  Kermit  options  (long  packets,  etc),  and  both  line  mode 
and  full  screen  connections. 
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--  Less  popular  micros  &  workstations  Ctape  O 


Prefix    Machine(s) 


Operating  System    Language 


AC 

Acorn  BBC  Workstat 

ion 

Panos 

C 

AM 

Alpha  Micro  68000 

AM0SL 

Alpha  Asm  68K 

APL 

Apollo 

Aegis 

Pascal 

APO 

Apollo 

Aegis 

Pascal 

BBC 

Acorn  BBC  Micro 

0Sl,2,3,Panos 

(various) 

CIE 

CIES  680/XX 

REGULUS 

C 

CN8 

(various) 

Concurrent 

CP/M-86 

ASM86 

EXP 

TI  Explorer 

Common  Lisp 

FL 

Motorola  6809 

FLEX-09  or 

SK*D0S 

C  or  6809  Asm 

HL6 

Honeywell  L6/10 

MS-DOS 

MASM 

HP2 

HP-264x 

? 

8080  Asm 

HP8 

HP-86,  HP-87 
HUCSD  p-System 

HP  BASIC 

HP  BASIC 

HP9 

HP  Pascal 

186 

Intel  86/380 

iRMX-86 

PL/M 

IRMX 

Intel  86/380 

iRMX-86 

PL/M 

LM 

LMI  or  Symbolics 

Lisp  Machines 

ZetaLisp 

LUX 

Luxor  ABC -800 

ABCD0S 

BASIC-II 

M2 

Lilith  Workstation 

Medos 

Modula-2 

MD2 

Intel  Development 

Syst 

em  ISIS 

PL/M 

MDS 

Intel  Development 

System  ISIS 

PL/M 

OS  9 

Various 

0s9 

C 

PQK 

ICL/3  Rivers  PERQ 

PERQ  OS 

Pascal 

PRO 

DEC  Professional-350 

P/OS 

Bliss 

QLK 

Sinclair  QL 

QDOS 

C 

QL2 

Sinclair  QL 

QDOS 

BCPL 
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Less  popular  micros  &  workstations  ftape  C)  Ccon'tl 


Prefix 


Machine(s) 


Operating  System    Language 


QNX  IBM  PC,  Rainbow,  etc 

RML  Research  Machines 

RMX  Intel  286/10,  etc 

TRI  various 

UCA  Apple  II 

UCI  IBM  PC 

UCJ  Joyce  Loebl  Magiscan 

UCM  Pascal  Microengine 

UCT  Terak  8510a 

UM  U-Micro  U-Man  1000 

VIC  Sirius  1/Victor  9000 


QNX 

c 

ROS,  . . . 

c 

RMX-86 

PL/M 

TRIPOS 

BCPL 

UCSD  p-System 

Pascal 

UCSD  p-System 

IV. 

X 

Pascal 

UCSD  p-System 

Pascal 

UCSD  p-System 

Pascal 

UCSD  p-System 

II. 

0 

Pascal, Macro-11 

CP/M-68K 

C  &  68000 

MS-DOS 

C 
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Less  popular  minis  &  mainframes  (tape  D1 


Prefix    Machine(s) 

Operating  System 

Language 

AOS 

Data  General 

AOS,  AOS/VS 

Fortan, Pascal 

B68 

Burroughs  B6800 

? 

Algol 

B78 

Burroughs  B7800 

&  A 

? 

Algol 

B79 

Burroughs  B7900 

? 

Algol 

CDC 

CDC  Cyber  170 

N0S 

Fortran-77 

CD3 

CDC  Cyber 

NOS 

Fortran  5 

CR 

Cray-1,  Cray-XMP 

CTSS 

Fortran-77 

*cuc 

(various) 

Unix 

C 

CVK 

Computervis  ion 

CGOS 

Fortran  S 

CYB 

CDC  Cyber 

NOS  2.  2 

Compass 

DGM 

Data  General 

AOS/VS  with  MV/UX 

C 

DTS 

Honeywell  6000 

DTSS 

Virtual  PL/I 

GEC 

GEC  4000  Series 

OS-4000  (RAL) 

SERC 

GM 

Gould/SEL-32 

MPX-32 

Fortran  77+ 

GUTS 

IBM  370  Series 

GUTS 

Assembler 

HI 

Harris  100 

VOS 

Fortran 

H8 

Harris  800 

VOS 

Pascal,  Asm 

HC6 

Honeywell  DPS  8, 

66 

CP6 

PL/ 6 

HCP 

Honeywell  DPS  8, 

66 

CP6 

Pascal 

HD6 

Honeywell  DPS  6 

GCOS  6 

?(no  source) 

HDP 

Honeywell  DPS  8, 

66 

GCOS 

B 

HG 

Honeywell  DPS  8, 

66 

GC0S3  or  8 

C 

HP3 

Hewlett-Packard 

3000 

MPE 

SPL 

HPM 

Hewlett-Packard 

1000 

RTE-6/VM  &  RTE-A 

F-77  &  Asm 
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■-   Less   popular  minis   &  mainframes    Ctape  D)    ('cont'd') 


Prefix    Machine(s) 

Operating  System 

Language 

IBM 

370  Series 

MUSIC 

Assembler 

K08 

DEC  PDP-8 

0S8,  RTS8 

PAL -8 

DEC 

PDP-8 

OS-278 

PAL -8 

MOD 

MODCOMP  Classic 

MAX  IV 

Fortran/ ASM 

MTS 

IBM  370  Series 

MTS 

Asm,  Pascal 

MT2 

IBM  370  Series 

MTS 

PLUS 

MU 

Honewyell 

MULTICS 

PL/ 1 

ND 

ND-10/100/500 

Simtran  III  Rev  J 

ND  Pascal  J 

CDC  Cyber 

NOS  2.4 

Compass 

PER 

Perkin-Elmer  3200 

OS/32 

Fortran 

Perkin-Elmer  3200 

OS/32  MT72 

Fortran 

PE7 

Perkin-Elmer  7000 

IDRIS 

C 

PIC 

Microdata  (McD-Dougl) 

REALITY  (PICK) 

DATA/ BASIC 

PRI 

PRIME 

PRIMOS 

PL/P  (PL/ I) 

RDOS 

Data  General  Nova 

RDOS 

Fortran 

RD2 

Data  General  Nova 

RDOS 

Basic 

RT 

PDP-11 

RT-11 

OMSI  Pascal 

SP9 

Sperry  90/60 

VS9 

Assembler 

ST 

HP3000,  Univac,  etc 

Software  Tools 

Ratfor 

TAN 

Tandem 

Nonstop 

TAL 

TI9 

TI-990 

DX10 

Pascal 

UN 

Sperry/Univac-1100 

EXEC 

Assembler 

VME 

ICL  2900 

VME 

S3 

vx 

VAX 

VMS 

Pascal  and  Fort 

ran 

*  UCL  C-Kermit  (Prefix  CUC,  Tape  D): 

A  trim  version  of  Kermit  from  England,  written  in  C,  without  all  the  fancy  features 
of  the  above  C-Kermit,  but  possibly  somewhat  more  efficient.  Runs  on  Berkeley  and 
ATT  Unix  systems. 
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--Documentation  sources,   mail  archives,   etc.  ("Tape  E~) 


BY  Byte  Mag  Kerrait  Article,  Jun-Jul  84 

GER  Kerrait  documentation  in.  .  . 

IBM  IBM  mainframe  Kermit  discussion  panel 

KP  Kermit  Protocol  Manual 

KU  Kerrait  User  Guide 

MA  Info-Kerrait  Electronic  Mail  Digests  '83-now 

NEW  Kermit  Newsletters 

POR  Kermit  documentation  in.  .  . 


English 

German 

English 

English 

English 

English 

English 

Portuguese 


*  Manuals  and  other  documentation  (Tape  E): 

Note:   The   protocol  manual   and  user  guide  were 
recently  moved  to  Tape  E  due  to  lack  of  space  on  the 
other  tapes. 

There  are  two  Kermit  manuals:  KUSER  and  KPROTO,  a  user's  guide  and  a 
protocol  manual,  respectively.   They  are  provided  in  three  forms: 

.MSS  Scribe  (UNILOGIC  Ltd  text  formatter)  source. 
.DOC  No  special  effects,  suitable  for  reading  at  a  terminal. 
.FOR  Fortran  carriage  control  for  overprinting,  etc. 

If  you  have  Scribe  and  the  appropriate  Scribe  device  drivers,  you  can  run  the 
.MSS  files  through  it  to  produce  output  suitable  for  printing  on  any  device  supported 
at  your  site,  including  the  Xerox-9700,  Imagen,  Apple  LaserWriter,  or  other 
multifont  laser  printers  or  photocomposers.  Note  that  some  parts  of  the  user  manual 
rely  on  underlining  to  clarify  examples;  the  underlines  are  missing  from  the  .DOC  files, 
but  will  be  produced  if  you  run  the  .MSS  files  through  Scribe  for  a  device  capable  of 
underlining  (line  printer,  daisy  wheel,  laser  printer,  etc). 

The  user's  guide  is  intended  for  users  of  Kermit  (including  those  who  want  to  install 
it),  the  protocol  manual  is  for  those  who  would  like  to  write  a  new  implementation 
(i.e.   a   Kermit  program  for  a  new  machine  or  operating  system). 
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IMPORTANT:  The  Users  Guide  is  always  out  of  date.  New  implementations 
ofKermit,  and  new  versions  of  old  ones,  arrive  in  a  steady  stream.  It's  impossible  to 
keep  the  manual  totally  current.  The  general  description  of  Kermit  operation  remains 
valid,  but  detailed  descriptions  of  the  various  versions  are  better  obtained  from  the 
accompanying  help  (.HLP),  beware  (.BWR),  documentation  (.DOC),  memo  (.MEM), 
or  manual  (.MAN)  files.  Look  to  these  files  for  information  missing  from  the  user 
manual. 

For  a  detailed  presentation  of  Kermit,  from  tutorials  on  computers,  files,  and 
data  communications,  to  a  thorough  description  of  the  protocol  itself,  plus  a  com- 
mand reference,  command  summary,  troubleshooting  guide,  glossary,  index,  and  many 
tables  and  illustrations,  see  the  book  "Kermit,  A  File  Transfer  Protocol,"  by  Frank  da 
Cruz,  Digital  Press  (1986),  ISBN  0-932376-  88-6,  available  from  Kermit  Distribution  at 
Columbia,  or  directly  from  Digital  Press,  12A  Esquire  Road,  Billerica,  MA  01862,  order 
number  EY-6705E-DP,  S25.00. 

ASCII. MSS  is  the  ASCII/EBCDIC  character  table,  which  is  included  as  an  ap- 
pendix in  both  manuals. 

KUSER.HYP  is  a  hyphenation  dictionary  for  building  the 
manuals  with  Scribe. 

BYTE.MSS   is  the  manuscript  of  the  KERMIT  article  that 

was  published  in  BYTE  Magazine  in  June  and  July, 

1984. 
BYTE. DOC  is  suitable  for  reading  at  the  terminal, 

BYTE.MSS   may  be  run  through   Scribe   to   produce 

output  for  various  printing  devices,   BYTE. BIB   is 

the  bibliography. 

MAIL.*  is  the  archive  of  the  CCNET/BITNET/ARPANET  KERMIT 

discussion  group. 
MAIL. TXT  is  the  current,  active  mail  file,  found  on  Tape  A. 


75 


MAIL.yyx  (e.g.    MAIL.83A)  files  contain  older  messages, 
and  these    are  kept  on  Tape  C. 

MAIL.HLP  describes  the  format  of  the  mail  files. 

***  IMPORTANT  *** 

Before  doing  anything  with  any  particular  version,  look  for  an  associated  file  with 
the  suffix  ".HLP"  (help)  or  ".BWR"  (beware).  These  files  will  often  tell  you  special 
things  you  should  know  before  starting  to  put  together  a  working  program  from  the 
distribution. 

*  MS-DOS  Kermit  Implementations  (Prefix  MS,  Tape  A): 

See  the  file  MSAAAA.HLP  for  an  explanation  of  MS-DOS  Kermit  file  naming 
conventions.  The  following  .BOO  files  are  provided  for  current  MS-DOS  imple- 
mentions.  BOO  files  are  downloaded  and  decoded  into  .EXE  files  using 
MSBOOT.FOR  on  the  mainframe  and  MSBPCB.BAS  on  the  MS-DOS  system,  or 
downloaded  directly  to  the  PC  and  translated  to  .EXE  files  using  MSBPCT.BAS  or 
MSBPCT.EXE  (compiled  from  MSBPCT.C),  or  MSBPCT.PAS  (Turbo  Pascal).  Some 
of  the  MSV*.BOO  files  correspond  to  version  2.30  of  MS-DOS  Kermit,  others  to  2.29, 
and  still  others  perhaps  even  to  earlier  version.  It  depends  on  which  was  the  latest  ver- 
sion successfully  tested  on  that  machine.  For  fallback  purposes,  BOO  files  for  old  re- 
leases for  some  systems  may  be  found  in  MSO*.BOO.  Beta  tests  of  new  releases  are 
in  MST*.BOO. 

MSV55X.BOO  Sanyo   MBC-550  with   IBM   compatible 

video  board 
MSVAP3.BOO         NEC  APC3 
MSVAPC.BOO         NEC  APC 
MSVAPR.BOO         ACT  Apricot 
MSVDM2.BOO  DECmate-11,111   with  XPU    (MS-DOS) 

option 
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MSVGEN.BOO         Generic  MS-DOS 
MSVGRI.BOO         Grid  Compass  II 

MSVHP1.BOO  Hewlett-Packard  150 
MSVHPX.BOO         HP-1 10  and  HP  Portable  Plus 
MSVIBM.BOO         IBM  PC,   Portable  PC,   XT,  AT,  PCjr**, 

and  compatibles 
MSVMBC.BOO         Sanyo  MBC-550 

MSVRB1.BOO  DEC  Rainbow  100  Series 
MSVRB2.BOO  A  special  fancy  Rainbow  version  that 

does  VT220  emulation 
MSVRMX.BOO         Intel  300  series  with  iRMX-86 

MSVTIP.BOO  Texas  Instruments  Professional  PC 
MSVWNG.BOO         Wang  PC 

MSVZ10.BOO  Heath/Zenith  100 

MXVV90.BOO  Victor  9000  (Sirius  1) 

Source  and  other  MS-DOS  Kermit  files: 

MSSDEF.H,MSS*.ASM  Sources 

MSG*ASM  System  dependent  graphics  terminal 

emulation 
MSU*.ASM  System  dependent  keyboard  support 

MSX*ASM  System  dependent  source  modules 

MSY*.ASM  Terminal  emulation  modules 

MSZ*.ASM  Continuation   of  terminal  emulation 

when  MSY  module  too  big 
MSKERM.DOC  Kermit  User  Guide  chapter  for   MS-DOS 

Kermit  (long) 
MSKERM.HLP         Brielf  list  of  MS-Kermit  commands 
MSKERM.BWR         "Beware    File"   -  Known    bugs    & 

limitations.  Read  it! 
MS*.HLP,   MS*.BWR  Help  and  Beware  files  for  specific 
systems. 
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The  IBM  version  runs  on  the  entire  IBM  PC  and  PS/2  families,  clones  and  compat- 
ibles (e.g.  Compaq,  AT&T  6300,  DEC  VAXmate),  and  near-clones  like  the 
Heath/Zenith  100  with  UCI  EZPC  board,  Olivetti  M24,  Seequa  Chameleon,  and  Data 
General/ 1. 

The  generic  version  (MSVGEN)  should  run  on  any  MS-DOS  system,  because 
it  operates  using  only  DOS  calls.  But  this  means  it  runs  slowly  (usually  1200  baud  or 
less),   and  cannot  do  fancy  screen  management  or  terminal  emulation. 

The  Tandy,  Honeywell,  and  some  other  MS-DOS  versions  listed  above  under  their 
own  prefixes  are  based  on  older  versions  of  IBM  PC  Kermit;  these  have  yet  to  be  merged 
with  the  current  MS/PC-DOS  version.   Volunteers? 

*  WKERMIT  (Tape  A): 

An  adaptation  of  an  early  version  of  C-Kermit  to  run  on  the  IBM  PC  family  and 
compatibles.  It  is  the  first  PC  implementation  of  Kermit  with  the  sliding  window  pro- 
tocol extension.  The  .EXE  file  is  formatted  as  a  .BOO  file  (see  above).  It  requires 
a  modem,  or  a  null  modem  cable  that  provides  normal  modem  signals.  The  source  code 
for  WKERMIT  should  not  be  used  as  the  basis  for  any  development,  as  it  is  several 
releases  behind  C-Kermit. 

*  WINKERM  (Tape  A): 

A  version  of  Kermit  specifically  tailored  for  the  multitasking  Microsoft 
Windows  environment. 

*  CP/M-80  Kermit  Implementations  (Tape  A): 

The  following  .HEX  files  for  specific  CP/M-80  implementations  are  in- 
cluded: 

CP4*.ASM       The  current,  working  source  files  for  CP/M 
KERMIT. 
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CP4KER.DOC       User  documentation  (chapter  from  the 
manual). 

CP4KER.HEX     System-independent  portion,  to  be  combined 
with   one   of  the  following   system-dependent 
"overlays": 

CP4380.HEX     Research  Machines  RM380Z 
CP438M.HEX     Research  Machines  RM380Z 
CP4820.HEX    Xerox  820 
CP4ACC.HEX    Access-Matrix 
CP4ADV.HEX    North  Star  Advantage 
CP4APC.HEX    Apple  II,  Z80  Softcard,  CPS  serial  card 
CP4APL.HEX     Apple   II,  Z80  Softcard,   6551   ACIA  in 

serial  interface 
CP4APM.HEX    Apple  II,  Z80  Softcard,   Micromodem  II  in 

slot  2 
CP4BB2.HEX    BigBoard  II  (terminal  required) 
CP4BBC.HEX    Acorn  BBC  Micro,  Z80  second  processor 
CP4BRA.HEX     Intertec  SuperBrain,  aux  port. 
CP4BRM.HEX     Intertec  SuperBrain,  main  port. 
CP4BRN.HEX    Intertec  SuperBrain. 
CP4CIF.HEX    Cifer  1886 
CP4COM.HEX    Comart  Communicator 
CP4CP3.HEX    "generic":  CP/M  3.0  (CP/M  Plus)  systems 

(terminal  req'd) 
CP4CPT.HEX      CPT-85xx  word  processors  with  CompuPak 

CP/M 
CP4CRO.HEX    Cromemco 

CP4DEL.HEX    Digicomp  Delphi  100  (terminal  required) 
CP4DIS.HEX    Action  Computer  Enterprises  Discovery 
CP4DM2.HEX    DECmate  II  with  CP/M  option 
CP4GEN.HEX    "generic":  CPM  2.2  systems  with  IOBYTE 

(terminal  req'd) 
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CP4H89.HEX     Heath/Zenith  H89. 

CP4H0R.HEX    North  Star  Horizon  without  SIO  board 

CP4HP1.HEX    Hewlett-Packard  125 

CP4KPR.HEX     Kaypro-II  (and  4;   probably  supports   all 

Kaypro  systems) 
CP4LOB.HEX     Lobo  Max-80 

CP4MDI.HEX     Morrow  Decision  I  (terminal  required) 
CP4MIK.HEX    MikroMikko 
CP4NST.HEX    Northstar  Horizon  with  Northstar  CP/M   and 

SIO-4  board 
CP40SB.HEX    Osborne  1 
CP40SI.HEX     Ohio  Scientific 

CP4PMM.HEX     Personal  Micro  Computer  MicroMate 
CP4PX8.HEX    Epson  PX8  Portable 
CP4ROB.HEX    DEC  VT180 
CP4TEL.HEX    TELCON  Zorba  portable 
CP4TLB.HEX    TRS-80  model  II  with  Lifeboat  2.25C   CP/M 

Display 
CP4TOR.HEX    BBC  Torch  Series 
CP4TPT.HEX    TRS-80  model  II  with  Pickles  +  Trout  CP/M 

Display 
CP4TTK.HEX    Teletek  with  ADM-22  terminal 
CP4UDI.HEX     Morrow    Micro   Decision    I    (terminal  required) 
CP4VEC.HEX    Vector  Graphics. 
CP4Z00.HEX    Z- 100  under  CP/M-85 

The    following  are  standalone  hex  files  that  can  be  directly  loaded  (not  combined 
with  CP4KER.HEX): 

CPMH8.HEX       Heath  H8  (based  on  version  3.5  of  CP/M-80 

Kermit) 
CPMPRO.HEX    Compupro  Interfacer  3/4  (based  on  version 

3.9) 
CPMSYO.HEX    Sanyo  MBC  1 100  (version  3.9) 
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The  Kermit  User  Guide  contains  instructions  for  installing  or  bootstrapping  the 
various  versions  of  CP/M  Kermit.  The  bootstrapping  program  is  also  stored  in  the 
files  CP4FET.*.  A  BASIC  program,  CP4HEX.BAS,  can  be  used  on  the  CP/M 
system  to  verify  and  edit  a  downloaded  hex  file  prior  to  loading. 

*  CP/M-86  Kermit  Implementations  (Tape  A): 

The  CP/M-86  Kermit  file  names  all  start  with  C86.  Those  whose  fourth  char- 
acter is  X   are   system-dependent   files   for  particular  systems: 

C86XAP  NEC  APC 

C86XFJ  Fujitsu  Micro  16s 

C86XFU  Future  FX20/FX30 

C86XRB  DEC  Rainbow,  CP/M-86/80  V2  (C86XR2  is  an 

alternate  version) 

C86XTX  Tektronix  4170 

C86XV9  Victor  9000/Sirius  1 

The  .H86  files  are  hex  files,  convertible  to  runnable  .CMD  files  by  running  them 
through  GENCMD  on  the  micro.  There's  also  a  Concurrent  CP/M-86  version  under 
the  prefix  C\8  (on  Tape  C). 

*  Queen's  University  Turbo  Pascal  Kermit  (Tape  A) 

Runs  on  several  systems.  All  source  files  concatenated  together  into  a  big  source 
file,   QKKER.PAS,  with  component  file  separated  by  lines  like 

(*  +FILE+  filename  *) 

The  runnable  program  image  (.COM  file)  is  encoded  into  straight  hexadecimal 
(2  hex  digits  for  one  byte  from  the   .COM  file)  for  the  following  systems: 

QKMSTV.HEX  IBM   PC  family,     MS-DOS,    with  VT100  & 
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Tektronix  4010  emulation 
QKMSVT.HEX        IBM    PC   family,     MS-DOS,  with  VT100 

emulation 
QKCPK2.HEX       Kaypro  II,  CP/M-80 
QKAPP2.HEX       Apple  II,  DOS 

A  simple  Turbo  Pascal  program  is  provided  to  convert  these  hex  files  back  into 
.COM  files  --  QKHEXC.PAS.  Key  definition  files  are  also  provided;  you  need  to 
have  one  on  your  current  disk  in  order  to  run  the  program. 

*  Other  Files  (All  tapes): 

AAAREAD.ME   is  a  file  that  describes  some   other  files 
which  can  help  you  find  your  way  among  the 
hundreds  of  Kermit  files. 

AAFILES.HLP  is  this  file. 

AATAPE.HLP  explains   the  format  and  layout   of  Kermit 
tapes. 

AAXFLY.DOC  is  the  Kermit  "brochure"  and  order  form. 

AAVNEW.HLP  is  a  list  of  the  current  versions  of  Kermit 
in  reverse  chronological  order,   to  help  you  see 
what  has  changed  since  the  last  time  you  looked. 

AAWAIT.HLP  is  a  list  of  Kermit  versions  reportedly  under 
development,  for  which  we  are  still  waiting. 

AAXCOM.HLP  is  a  policy  statement  concerning  commercial 
use  of  Kermit. 

AABLIND.HLP  is  a  list  of  hints  for  use  of  Kermit,   and 
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microcomputers  in  general,   by  the  blind  or  people 
with  other  disabilities. 

KERMIT.FOR  is   a  short  receive-only  version   of  Kermit 
written  in  Fortran,   to  be  used  for  bootstrapping 
Kermit  onto  systems  that  don't  have  a  real   Kermit 
from  a  system  that  does. 


*  Tools  (Tape  A): 

LASM  and  MLOAD  are  the  public-domain  CP/M-80  linking  assembler  and 
loader,   that  run  on  the  CP/M  system,   and    may  be  used  to  build  Kermit-80. 

UUDECO.C  is  a  version  of  UUDECODE  that  has  been  changed  to  supply  any 
trailing  blanks  on  lines  in  UUENCODEd  files  that  may  have  had  them  stripped  off 
by     electronic  mail  (like   on  BITNET). 

XXU.C  is  a  program  for  use  on  Unix  systems  that  renames  files  with  "foreign" 
names  (e.g.  uppercase,  or  including  directory  or  path  information,  generation 
numbers,   etc),  to  have  normal  Unix-style  names. 

XXTAPE.*  is  a  program  to  write  ANSI  and  EBCDIC  labeled  tapes  on  a  Unix 
system.  Also  needs  XXATOE.C. 

APXA*.*  is  a  program  written  in  C  that  does  what  CROSS  does,  but  only 
produces  6502  output  (CROSS  can  produce  many  formats).     This    program   can 

assemble  Apple   DOS    Kermit  (APPLEK.M65).     (Actually,  there  might  be 

minor  differences  in  syntax,   like  whether  or         not  a  colon  is  required  after  a  label...) 

*  DEC- 10/20  Tools: 

The  following  tools  are  specific  to  DECsystem-10  and  DECSYSTEM-20  com- 
puters, and  will  not  appear  on  distribution  tapes  for   other  kinds  of  systems,    and  will 
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only  appear  at  the  end    of  DEC- 10/20  tapes  if  there  is  sufficient  room.    The  tools  files 
are  stored  separately  in  KT:,  <  KERMIT-TOOLS>  . 

The  files  MAC80.*,  M80UNV,  etc,  are  an  8080/8085/Z80  cross  assembler  that  runs 
on  the  DEC-10  or  DEC-20;  MAC80.DOC  is  a  brief  description.  TORTUR.M80  is 
an  8080  instruction   set  "torture  test"  for  MAC80,  which  illustrates  its  features. 

ZORTUR.M80  is  a  Z80  instruction  set  torture  test.  MAC80  is  used  to  assemble 
CP/M  KERMIT,  and  is  mostly  compatible  with  the  standard  CP/M  8080  assembler, 
D.R.  ASM. 

HEXIFY.*  is  a  program  for  converting  a  CP/M  .COM  file  resident  on  the 
DEC-10  or  DEC-20  to  a  CP/M  .HEX  file.  This  is  handy  when  binary  file  transfers 
are  failing  to  work  for  some  reason.  The  .HEX  file  can  be  LOADed  on  the  CP/M 
system  in  the  normal  way  to  reconstruct  the  original  .COM  file.  HEXCOM.*  is  the 
inverse   of      HEXIFY,    and  provides   .HEX-to-.COxM   file  conversion. 

The  files  CROSS.*  are  a  general  purpose  cross  assembler  that  runs  only  on  the 
DEC-10  and  -20;  CROSS.DOC  is  the  manual.  CROSS  is  used  to  assemble  Apple  DOS 
and  Commodore-64  Kermits. 

WRITEL  is  a  program  to  write  ANSI  labeled  ASCII  tapes  on  the  DEC-20;  it  is 
written  in  Rutgers  Pascal,  and  requires  that  you  have  the  Rutgers  Pascal  runtime 
library  on  your  system. 


*  Finally... 

If  you  make  any  significant  modifications  to  Kermit,  fix  any  major  bugs,  or  write 
any  new  implementations  or  documentation,  please  send  them  back  to  us  onmagnetic 
tape  (or  IBM  PC  DOS  format  diskettes)  so  we  can  distribute  them  toother  Kermit  users: 

Kermit  Distribution 
Columbia  University 
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Center  for  Computing  Activities 
612  West  115th  Street 
New  York,  NY   10025 

We'll   return  your  tapes  back  to  you  with  the   latest 
Kermit   distribution  (if  you   send  full-size  reels). 
Specify   format  and  tape  selection  according  the    Kermit 
order  form  (copy  in  AAXFLY.DOC). 


*  OTHER  WAYS  TO  GET  KERMIT  * 

To     get   Kermit   on  magnetic  tape  from    Columbia 
University,     follow    the    directions   in    the    file 
AAXFLY.DOC.   There  are  also  other  ways  to  get  Kermit: 

.  Network  Distribution: 

The    file  AANETW.HLP  contains    instructions    for 
accessing   the   Kermit   distribution  over  a  variety   of 
computer  networks  and  dialup  hosts.  AANOKS.DOC  tells  in 
detail  how  to  access  the  Kermit   archive  at  Oklahoma 
State  University. 

.  Floppy  Disk  Distribution: 

A  list  of  volunteer  individuals  and  organizations  distributing  Kermit  on 
floppy  disks  of  various  formats  can  be  found  in  the  file  AADISK.HLP.  Kermit 
diskettes  may  also  be  ordered  in  several  formats  from  Columbia  University  (see 
AAXFLY.DOC). 

.  Overseas  sources  for  Kermit  Distribution  tapes: 

UK   and  Ireland  (ANSI  and  VAX/ ViMS   BACKUP  tapes,   selected  diskettes): 
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Alan  Phillips 

Communications  Group 

Department  of  Computing 

Computer  Building 

Lancaster  University 

Lancaster  LAI  4YW,  ENGLAND 

Phone  0524-65201  x4881 

France,  Belgium,  etc  (European  ANSI  tape  distribution  tree) 

Jean  Dutertre 

Institut  Francais  du  Petrole 

BP  311 

92506  Rueil  Malmaison  Cedex,  FRANCE 

Phone  +33  1  749.02.14 

West  Germany  (ANSI  tapes): 

Dr.  Hans-Magnus  Aus 

Institut  fuer  Virologie  und  Immunbiologie 

Universitaet  Wuerzburg 

Versbacherstrasse  7 

D-8700  Wuerzburg 

WEST  GERMANY 

Phone  (931)  201-3954 

Australia: 

Rodney  Van  Cooten  (or  The  Kermit  Coordinator) 

University  Computing  Services 

University  of  Melbourne, 

Parkville, 

Victoria,  3052, 
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AUSTRALIA 

E-Mail:  "munnari!murdu.oz!rvc"(a)SEI SM0.CSS.GOV 


Japan 


Ken-ichiro  Murakami 
NTT  Basic  Research  Laboratories 
3-9-11  Midori-cho,  Musashino-shi 
Tokyo,  180 
JAPAN 

Telephone  :  0422-59-3589 

E-mail  address  :   "nttlab!murakami"@ Shasta       (from 
ARPA)  or  murakami@nttlab.ntt.junet      (from     JUNET,     the 
Japanese  domestic  network.) 
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APPENDIX  D.     ACCESSING  KERMIT  FILES  VIA  COMPUTER 

NETWORKS 

This  file  is  resident  on  the  Columbia  University  Center  for  Computing   and   was  accurate 
as  of  20  Jan  88.     It  is   up-dated  yearly. 


This  file  describes  how  to  get  Kermit  files  over  computer  networks,  including 
BITNET,  CCNET  (a  DECnet  network),  the  Internet  (Arpanet  and  the  networks 
connected  to  it),  plus  various  dialup  accesses  including  UUCP.  You  should  also  read 
AAFILES.HLP  if  you  need  more  complete  descriptions  of  the  Kermit  files  them- 
selves. 


*  BITNET  from  the  Columbia  University  CUVMA  System: 

BITNET  is  a  network  of  computers,  mostly  at  universities,  connected  with  leased 
phone  lines,  using  IBM  mainframe  RSCS  protocols  (VAX  VMS  and  Unix  systems 
and  other  systems  that  can  imitate  these  protocols  are  also  on  BITNET).  BITNET 
covers  North  America,  Europe  (where  it  is  called  EARN),  and  has  recently  spread 
to  the  Far  East.  Information  about  joining  BITNET  may  be  obtained  from 
EDUCOM  Networking  Activities,  P.O.  Box  364,  Princeton,  NJ  (USA)  08540,  Phone 
609-734-1878. 

KERMSRV  at  CUVMA  is  a  file  server  for  the  BITNET  user  community  which 
accepts  commands  via  messages  or  spool  files,  and  sends  the  requested  KERMIT  files 
over  the  network.  Most  spool  file  formats  are  accepted  including  those  used  by 
SENDFILE,  NOTE,  PUNCH,  PRINT,  CARD  DUMP,  or  DISK  DUMP  commands. 

To  learn  how  obtain  Kermit  files  from  the  Columbia  IBM  mainframes  via 
BITNET,  type  the  following  command  to  your  BITNET  host: 

VM/CMS:        TELL   KERMSRV  AT  CUVMA   HELP  (or  SMSG   RSCS 
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MSG  CUVMA  KERMSRV  HELP) 
MVS/TSO/E:   TELL  KERMSRV  AT  CUVMA  HELP  (syntax  may   be 

site  dependent) 
VMS  JNET:     SEN/REM  CUVMA  KERMSRV  HELP 
UNIX  UREP:   netexec  cuvma  msg  cuvma  kermsrv  help 

The  Kermit  files  available  from  BITNET  may  be  some  days  or  weeks  behind  the 
announcements  that  appear  in  Info-Kermit  (see  below). 

Here  is  a  brief  summary  of  KERMSRV  operation;  see  the  HELP  message  for 
greater  detail: 

The  following  file  request  commands  are  accepted:  SEND,  MAIL,  PUNCH, 
PRINT,  DISK,  and  CARD.  These  commands  expect  a  file  name  or  "DIR"  or  "?"  as 
an  operand.  The  DIR  operand  accepts  an  optional  file  name  also.  File  names  may 
contain  *  or  %  wildcard  characters,  but  the  filename  portion  may  not  consist  of  those 
characters  only. 

Note  that  KERMSRV  will  always  respond  with  some  message;  if  you  get  a  response 
please  do  not  resubmit  your  request.  If  your  request  was  received  as  a  spool  file,  error 
messages  are  sent  in  a  spool  file,  also. 

The  NEWS  command  returns  news  about  latest  features  and  changes  in 
KERMSRV. 


*  BITNET  from  the  University  of  Toledo  VAX/VMS  system  UOFT02: 

The  Kermit  file  server  KERMSRV  is  not  the  same  one  as  the  one  running  at 
Columbia  --  this  is  a  VAX,  and  CUVMA  is  an  IBM  mainframe.  The  collection  is 
maintained  by  Brian  Nelson,  author  of  PDP-11  Kermit,  mail  to  BRIAN@UOFT02  on 
BITNET. 

for  instance,  from  VM/CMS: 
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CP  SMSG  RSCS  MSG  UOFT02  KERMSRV  DIR 
CP  SMSG  RSCS  iMSG  UOFT02  KERMSRV  SEND  Kll*.* 
(or  TELL  KERMSRV  AT  UOFT02  DIR,  etc.) 

from  VMS  Jnet:    S  SEN/REM  UOFT02  KERMSRV  SEND  Kll*.* 

Attempts  to  see  if  Kermsrv  is  'logged  in',  e.g.  SEN/COM  UOFT02  CPQ  U 
KERMSRV  or  SM  RSCS  MSG  UOFT02  KERMSRV  CPQ  U  KERMSRV  will  AL- 
WAYS fail.  This  is  a  VMS  node  running  JNET  and  JNET  treats  server  processes 
in  a  manner  unlike  VM  does. 

For  all  pratical  purposes,  KERMSRV  is  always  running.  If  a  message  is  sent  to  it, 
and  for  some  reason  it's  not  there,  JNET  will  tell  you. 

Secondly,  KERMSRV  can  ONLY  respond  to  interactive  messages,  it  can  not 
process  mail. 

Additional  "satellite"  BITNET  KERMSRV  sites  may  be  established  in  the 
future  to  relieve  congestion  at  the  major  US  East  Coast  hubs.  The  need  is  particularly 
great  on  the  West  Coast  and  in  Europe.  Volunteers?  There  is  also  some  possibility 
of  converting  from  KERMSRV  to  the  more  general  and  powerful  LISTSERV  fa- 
cility. 

*  Internet  from  the  Columbia  University  CU20B  System: 

"Internet"  means  the  Arpanet  and  any  network  connected  to  it  using  TCP/IP  pro- 
tocols, including  parts  of  CSnet,  many  campus  local  networks,  etc.  Access  to  the 
Columbia  Internet  Kermit  distribution  is  through  FTP,  the  Internet  File  Transfer 
Program;  consult  the  FTP  manual  for  your  own  system  in  order  to  learn  how  to  use 
your  FTP  program. 

To  get  Kermit  files  via  the  Internet,  use  FTP  (not  TELNET),  connect  to  host 
CU20B  (Internet  Host    number    ffll28.59.32.128"),  login    as    user  ANONYMOUS, 
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password  KERMIT,  and  use  the  GET  or  MULTIPLE  GET  commands  to  retrieve  the 
desired  files  from  the  area  KER:,  e.g.  "GET  KER:AAAREAD.ME",  "MULTIPLE 
GET  KER-.CK*.*".  Network  users  may  consult  the  file  KER:AAVNEW.HLP  from 
time  to  time  to  see  what  new  versions  of  Kermit  have  been  installed  recently.  Sites 
whose  FTP  programs  do  not  support  the  DIRECTORY  or  MULTIPLE  GET  com- 
mands may  GET  the  file  AAFILx.DIR  from  the  desired  Kermit  area  (see  below)  to 
obtain  an  up-to-date  directory  listing. 

After  logging  in  anonymously,  you  may  also  attempt  to  set  your  default  path  to 
the  desired  Kermit  directory,  KER:,  K2:,  K3:,  K4:,  or  K5:  (see  below),  using  FTP's 
CWD  or  CD  command.  If  you  are  prompted  for  a  password,  provide  a  null  one;  if  a 
message  advises  you  to  send  a  password,  ignore  the  message.  Since  our  network 
software  is  always  in  a  state  of  transition,  this  operation  may  or  may  not  work. 
The  following  discussion  assumes  it  does  not  work;  if  it  does,  you  can  follow  the 
same  instructions,  but  leave  off  the  prefix  KER:,  K2:,  K3:,  etc,  from  any  file  specifica- 
tions.    (But  if  an  operation  fails,   then  try  again  but  with  the  prefix.) 

Internet  access  to  CU20B  is  currently  unrestricted,  but  if  sufficiently  large  num- 
bers of  anonymous  FTP  logins  occur  regularly  during  prime  (eastern)  time  hours  to 
interfere  with  our  own  user  community,  some  restrictions  on  anonymous  logins  will 
have  to  be  imposed. 

Those  accessing  CU20B  via  network  should  note  the  existence  of  several  Kermit  file 
areas: 

KER:    -  Popular  microcomputer,  PC,  workstation  Kermit 

implementations. 
K2:      -  Popular  mainframe  and  minicomputer   Kermit 

implementations. 
K3:      -  Less  popular  micro  &  PC   Kermits  (spillover 

from  KER:). 
K4:       -  Less    popular  mini  &  mainframe     Kermits 

(spillover  from  K2:). 
K5:      -  Mail  archives,  full-text  user  guide,  protocol 
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manual,  etc. 
KB:      -  True   binary  (executable)  files  for   selected 

implementations. 
KE:      -  "Extra",  old,  redundant,  or  "limited-edition" 

Kermit  implementations. 
KT:      -  Tools  —  cross  assemblers  and  linkers,   etc., 

mostly  to  run  on  DEC-20. 
KO:     -  Old  releases  superseded  by  new  ones. 

KER:   corresponds  to  Tape  A,    K2:  corresponds  to  Tape  B, 
to  Tape  C,  K4:  to  Tape  D,  K5:  to  Tape  E. 

These  areas  are  "logical  device  names",  which  should  be  used  rather  than  physical 
DEC-20  DEVICE:  <  DIRECTORY >  names,  which  may  change  from  time  to  time 
as  our  systems  are  rearranged.  The  logical  name  KER:  includes  all  the  others  (K2:, 
KB:,  etc)  in  its  search  path  in  the  order  listed  above,  so  to  obtain  a  single  file  you  should 
prefix  its  name  by  KER:. 

When  getting  either  single  or  multiple  files,  and  your  own  system  is  a  DEC-20, 
then  it  is  also  sufficient  to   prefix  the  file  specification  by  KER:. 

When  getting  multiple  files  from  CU20B's  FTP  server  from  non-DEC-20  systems, 
you  should  first  change  working  directory  (CWD  or  CD)  to  the  area  containing  the 
files  you  want  to  get,  e.g.  KER:  or  K2:.  If  you  don't,  then  each  file  will  be  sent  back 
to  you  with  its  fully  qualified  name  which  in  some  cases  may  be  longer  than  the 
longest  permissible  filename  on  your  system,  which  in  turn  can  cause  files  whose 
names  differ  only  in  the  last  few  characters  to  overwrite  each  other  as  they  arrive. 

Alphabetic  case  is  insignificant  in  DEC-20  file  names  (lowercase  is  mapped  to 
upper).  The  dot  separating  the  file  name  and  file  type  is  significant;  the  name  and  type 
are   separate  fields. 

File  groups  may  be  specified  in  MULTIPLE  GET  commands  using  the  following 
"wildcard"  notation: 
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*    matches   any  string  of  0  or  more  characters  in  the 
current  field 

%    matches  any  single  character  in  the  current  position 


For  instance,  KER:CK*.*  matches  all  files  whose  names  start  with  CK. 
KER:CK*.%  matches  all  files  whose  names  start  with  CK  and  whose  types  are 
exactly  one  character  long  (like  KER-.CKUCMD.C).  The  dot  in  DEC-20 
filenames  separates  the  filename  from  the  filetype.  KER:*  will  NOT  match  all  the  files 
in  KER:  (as  Unix  users  might  expect),  but  rather,  all  the  files  in  KER:  that  have  null 
filetypes.    Use  *.*  to  match  all  files. 

Each  implementation  of  Kermit  has  a  additional  prefix  imbedded  in  the  name. 
All  files  relating  to  that  implementation  have  names  that  start  with  that  prefix.  Since 
the  dot  is  significant  in  DEC-20  file  names,  the  way  to  refer  to  all  the  files  in  a 
specific  implementation  is  "KER:xx*.*",  where  xx  is  the  prefix,  e.g.  KER:MS*.*  for  all 
the  MS-DOS  Kermit  files. 

A  few  cautionary  words  about  DEC-20  logical  names:  the  search  path  is  followed 
only  so  long  as  files  are  not  found  that  match  the  given  file  specification.  This  can 
cause  some  confusion;  for  instance,  the  command  "DIRECTORY  KER:"  will  only  list 
the  files  in  the  primary  (Tape  A)  Kermit  directory,  because  when  no  file  specification 
is  given,  "*.*"  is  assumed,  and  all  files  in  the  primary  directory  match  "*.*",  so 
subsequent  directories  are  not  searched.  Similarly,  "KER:C*.*"  will  not  search  sub- 
sequent directories  if  the  primary  directory  contains  any  files  that  start  with  "C".  Note 
that  "KER:*. DOC"  (whose  intention  might  be  to  refer  to  all  the  Kermit  doc- 
umentation files)  would   only   find   .DOC   files   in  the   primary     Kermit  directory. 

Care  has  been  taken  to  ensure  that  files  are  arranged  so  that  if  they  are  referred 
to  by  prefix,  they  will  be  found  in  the  KER:  search  path.  For  instance,  the  C-Kermit 
files,  having  the  prefix  "CK"  will  be  found  if  referred  to  as  "KER:CK*.*",  even  though 
they  are  really  in  K2:.     However,  this  principle  applies  only  to  the  principal  directories, 
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KER:,  K2:,  K3:,  K4:,  and  K5:.  It  does  not  apply  to  KB:,  which  is  used  to  separate  bi- 
nary files  from  "printable"  files.  Therefore,  KER:MS*.*  will  find  all  of  the  printable 
MS-DOS  Kermit  files,  but  will  not  find  the  .EXE  files,  which  are  in  KB:,  and  must 
be  referred  to  separately  as  KB:MS*.*. 

Before  you  attempt  to  get  binary  files  from  the  KB:  or  KT:  directories  with  FTP, 
you  should  know  something  about  the  way  the  DEC-20  stores  these  files: 

.   Native   DEC- 10  or  DEC-20  programs  are  stored  in  36- 
bit  binary  format,  and  will  be  transferred  correctly  to 
other   DEC- 10   or  -20  systems  without   doing      anything 
special.     They  probably  can't  be  transferred  to   other 
kinds   of  systems,   except  maybe  36-bit   Honeywells   or 
Sperrys. 

.   "Foreign"   8-bit  binary  files  are  stored  four  8-bit 
bytes  left  justified  within  the  36-bit  word.     You  can 
get   these   files   from  another  DEC-10  or  -20    without 
doing  anything  special,   but  to  get  them  from  some  other 
kind  of  system,  you  have  to  give  FTP  the  command  "TYPE 
L  8",  "type  binary",  and/or  "TENEX"  first. 

If  you  are  originating  your  FTP  requests  from  a  DEC-20  or  TENEX  system,  no 
special  precautions  are  necessary  regarding  file  types  or  name  conversion.  If  you  are 
coming  from  another  kind  of  system,  you  will  probably  find  that  the  files  you  obtain 
are  stored  with  names  contrary  to  your  system's  naming  conventions.  For  instance, 
if  you  tell  Unix  FTP  to  "mget  kerxk*.*",  you  may  find  the  files  stored  in  your  directory 
with  names  like 

PK:  <  KERMIT>  CKAAAA.HLP.2 

when  you  really  want  stored  with  names  like 

ckaaaa.hlp 
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A  special  program  is  available  to  Unix  sites  for  doing  the  appropriate  file  name 
conversions,  called  xxu.c  ("get  kenxxu.c").  The  recommended  procedure  for 
FTP'ing  files  to  a  Unix  system  is  to  make  a  new  directory  for  them,  cd  to  it,  then  get 
the  files,  including  kenxxu.c,  then  build  xxu.c  (just  type  "cc  -o  xxu  xxu.c";  the  result 
should  run  under  any  version  of  Unix),  then  do  "xxu  *"  to  convert  the  names.  See 
the  xxu.c  source  comments  for  details. 


USING  KERMIT  WITH  AN  INTERNET  TERMINAL  ACCESS  CONTROLLER 

(TAC). 

(Thanks  to  Edward  Haines  <  haines@BBNCCI.ARPA>  for  these  hints) 

There  are  some  conditions  that  must  be  met  to  successfully  use  Kermit  on  a  per- 
sonal computer  through  a  TAC. 

Flow  Control 

The  buffer  size  for  a  terminal  port  on  a  TAC  is  typically  about  64  bytes.  (The  size 
is  a  configuration  parameter.)  Since  the  default  packet  size  in  Kermit  is  usually  80-96 
bytes  it   is  quite  likely  that  buffer  overflow  will  occur. 

Some  possible  solutions: 

1.   Enable  flow  control  in  Kermit  on  the  PC  and  on  the 
TAC.   Many  PC  versions  of  Kermit  implement  XON/XOFF  flow 
control,   including  the  MS-DOS  version  for  the  IBM    PC. 
To  enable  flow  control  on  the  TAC  issue  the  TAC  commands 

@Flow  Input  Start 
@Flow  Output  Start 

These  are  usually  abbreviated  @f  i  s  and  @f  o  s.    Note 
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that  flow  control  is  not  compatible  with  binary  mode 
(except  see  note  below). . 

2.  Make  the  packet  size  on  the  PC  Kermit  small  enough 
to   not  overflow  the  TAC  buffer,   e.g.   60   bytes.     The 
normal  command  is  "set  receive  packet-length  60",  which 
you  give  to  the  Kermit  that  is  about  to  receive  files. 

3.  Increase  the  buffer  size  in  the  TAC.   This  is  not 
usually  practical  and  won't  be  considered  further. 


TAC  Intercept  Character. 

The  default  TAC  intercept  character  is  the  AT-sign.  The  AT-  sign  is  also  required 
by  the  Kermit  Protocol,  so  unless  you  take  one  of  the  measures  listed  below,  Kermit 
packets  won't   get  through  the  TAC. 

Solutions 

1.  Have  the  PC  Kermit  automatically  double  AT-signs  on 
output.    This  is  probably  the  best  solution  in  general. 
This  feature  is  available  on  some  PC  implementations   of 
Kermit.     It  is  not  yet  available  on  the  MS-DOS  version. 
fflEd.  -  It's  available  in  CP/M-80  Kermit  4.0x." 

2.  Change  the  TAC  Intercept  character  with  the  command 
©Intercept  <  decimal  ASCII  value > 

For  instance,  "@I  6"  sets  the  intercept  character  to  Ctrl-F. 

3.  Put  the  TAC  into  Binary  mode.    This  has  the   side 
effect   of  disabling  the  Intercept  character.     It  also 
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will  allow  you  to  transfer  binary  files  without   special 
encoding.     The  TAC  can  be  put  into  Binary  mode  with  the 
commands 

@Binary  Input  Start      (@b  i  s) 
@  Binary  Output  Start    (@b  o  s) 

Some  host  systems  allow  you  to  engage  the  binary   mode 
from  the  host.  DEC-20  Kermit  has  a  command  for  this. 

There  are  several  problems  with  binary  mode: 
Some  host  systems  don't  support  it. 
You  lose  the  ability  to  control  the  TAC  from  the  PC. 
You  lose  the  ability  to  do  XON/XOFF  flow  control. 

Binary  Files 

It  is  sometimes  desireable  to  be  able  to  transmit  an  8-bit  binary  file  between  a  host 
and  a  PC.  The  TAC  (which  implements  the  DDN  Telnet  Protocol)  normally  provides 
just  a   7-bit  ASCII  path. 

Solutions 

1.  Enable  binary  mode  (if  possible)   as   described 
above. 

2.  Enable   8th  bit  prefixing  (if  available)  in  both 
Kermits.    (This  is  usually  done  by  enabling  parity  via 
Kermit's  SET  PARITY  command.) 


Notes 


1.      You    will  probably   get    the     best 
throughput   for  ASCII    files  by   keeping  the 
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packet   size   as  large  as  possible   and   using 
flow  control. 

2.  There    is  not   much    advantage    in 
increasing   the  baud  rate  between  the  PC   and 
the  TAC   beyond   1200  baud  because   of  the 
relatively    long  turnaround  time  for    the 
acknowledgement  packet. 

3.  You  may  have  problems  when  going  through 
satellite  hops  or  multiple  gateways  due  to  the 
occasional  very  long  delays.     This  may  result 

in   Kermit   giving  up.     The  problem  can  be 
circumvented   to   by  increasing   the   timeout 
interval;   many  Kermits  have  commands  to  allow 
this:  SET  SEND/RECEIVE  TIMEOUT. 

4.  Only  the  first  letter  of  a  TAC  command 
is  required. 

5.  It  is  possible  to  set  binary  mode  in 
only   one  direction.     For  example  you  can  set 
Inbound  binary  and  retain  input  flow  control 
(XON/XOFF  flow  is  in  the  opposite   direction). 
You  probably  don't  need  outbound  (input  to  the 
PC)    flow  control  when  using  the    Kermit 
protocol. 


*  CCnet: 

CCnet  is  a  DECnet  network  of  cooperating  universities.  Kermit  files  may  be 
accessed  using  NFT  to  CU20B::KER:xxx.yyy,  where  xxx.yyy  is  the  name  of  the  file 
or  file  group  you  want   to  get.      Some    sites    (regarded    as    "secure")    may    specify 
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/USERANONYMOUS,  but  most  sites  will  have  to  supply  a  valid  CU20B  user  ID  and 
password.  If  your  system  is  on  CCnet  and  you  cannot  get  anonymous  NFT  access  to 
CU20B,  you'll  have  to  ask  your  system  manager  to  get  the  files  for  you.  Read  the 
Internet  section  above  about  device,  directory,  and  wildcard  conventions. 


*    United   Kingdom  (Information  from  Alan   Phillips,    Lancaster  University): 

Though  there  is  a  central  registry  of  UK  site  names  known  as  NRS,  it  is  not  auto- 
matic and  many  people  have  no  access  to  it,  so  include  the  actual  DTE  addresses  if  you 
can.    Details  for  mail: 

JANET  network  :       SYSKERMIT  @  UKAC.LANCS.VAXl 

(actual  address  is 

000010404000.FTP.MAIL) 

PSS  network    :        SYSKERMIT@234252400101. 
000010404000.FTP.MAIL   or    to 
the  JANET  address  via  the 
Rutherford  gateway 

BITNET  :       SYSKERMIT%LANCS.VAX1  @  UK.AC 

ARPA  :       SYSKERMIT%LANCS.VAX1  @  CS.UCL. 

AC.UK 

We  do  not  support  file  transfer  to  BITNET/ ARPA  -  users  have  to  log  in  as  a  ter- 
minal and  use  KERiMIT.  Over  PSS  and  JANET  we  support  ftp  using  Blue  Book 
protocol:  For  details  pull  file  00INFO.TXT  from  user  KERMIT,  quoting  password 
KERMIT.  FTP  address  is 

JANET  :   0000 10404000. FTP 

PSS  :   234252400101. 000010404000.  FTP" 
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Or  people  can  just  mail  me  and  I'll  send  details.  Afraid  we  have  no  equivalent  of  the 
BITXET  KERMSRV  server  or  Arpa  anonymous  ftp  over  here.  Dial-up  ports  are 
available;  I'll  send  details  to  anyone  wanting  them. 

While  we're  very  happy  for  anyone  to  ftp  from  us  or  log  in  to  us  from  anywhere, 
and  we'll  put  anyone  on  the  mailing  list,  we  can't  handle  letters  and  phone  calls  from 
outside  the   UK   and  Eire.   Nor  can  we  send  files  to  people  who  can't  ftp  them. 


Mail: 


There  is  a  network  mailing  list  for  Kermit  information;  it  is  available  to  users 
of  BITNET  and  the  Internet  and  most  networks  that  are  connected  to  them, 
inclusing  CSnet,  Usenet,  Mailnet,  CCnet,  and  others.  To  get  on  the  mailing  list,  send 
mail: 


-  From  -  -  To  - 

BITNET  KERMIT@CUVMA 

CCNET  Info-Kermit-Request@CU20B 

Arpa  Internet  Info-Kermit- 

Request@CU20B.COLUMBIA.EDU 
CSNET  Info-Kermit-Request%CU20B.COLUMBIA. 

EDU@CSNET-RELAY 
Mailnet  Info-Kermit-Request%CU20B.COLUMBIA. 

EDU@MIT-MULTICS 
Usenet  ...!uunet!columbia!cu20b!info- 

kermit-request 
DEC  Easynet       DECWRL::"Info-Kermit-Request@CU20B. 

COLUMBIA.EDU" 


UK  JANET 


SYSKERMIT@UK.AC.LANCS.VAX1 


If  your   system  won't  let  you  use  long  names  or  names   with  dashes   in   mail  ad- 
dresses,  then  just   substitute   "KERMIT"   for  "Info-Kermit-Request". 
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Also,  as  of  December  1988,  the  Kermit  mailing  list  is  available  via  BITNET 
LISTSERV.  This  is  a  facility  that  lets  you  subscribe  and  unsubscribe  yourself.  To 
subscribe  via  LISTSERV,  send  an  electronic  mail  message  to  LISTSERV@CUVMA. 
The  body  of  the  message  should  contain  the  line: 

SUBSCRIBE  I-KERMIT  your  personal  name 

For  instance 

SUBSCRIBE  I-KERMIT  Fred  C.  Dobbs 

To  remove  yourself  from  the  list,  send  the  following  message: 

UNSUBSCRIBE  I-KERMIT 

To  learn  more  about  LISTSERV,   send  it  a  message  "HELP"  or  "INFO  ?". 


*  Dialup: 

Several  publicly  accessible  dialup  Kermit  collections  are  available  in  the  US: 

1.  The  University  of  Toledo  allows  limited  dialup  access  to    its  UOFT02  VAX/VMS 

system: 

(419)537-4411 
Service  class  VX785A 
User:  KERMIT 
Password:  KERMIT 

Source  and  hex  files  are  in  KER:,  binaries  are  in  KERBIN: 

2.  Oklahoma  State  University: 
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UUCP  and  Kermit  access  to  the  complete  Kermit  distribution  is  available  from  the 
Department  of  Computing  and  Information  Sciences,  Oklahoma  State  University, 
Stillwater,  Oklahoma.  The  procedures  are  somewhat  complicated,  and  are  described 
in   a  separate  file,  AANOKS.DOC. 
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APPENDIX  E.     KERMIT  USER'S  GUIDE 

This  is  a  step-by-step  guide  for  using  KERMIT  to  access  the  NPS  mainframe  from 
a  Heath/Zenith  100  or  89  microcomputer.  The  procedures  were  developed  by  the  long 
proven  scientific  trial  and  error  method  and  some  very  old  notes  from  a  1984  file  on  the 
mainframe  titled  "Z100h89  fullscrn  B".  If  you  happen  upon  improvements  and/or  cor- 
rections to  this  guide,  please  provide  them  and  any  other  comments  to  the  computer 
department  so  they  can  be  added.  This  and  the  other  KERMIT  text  files  were  written 
by  R.  G.  Bishop  in  April  1987  at  the  request  of  the  NPS  Computer  Center. 

A.  KERMIT  IN  GENERAL 

There  are  many  help  files  and  documents  available  to  help  you  become  familiar  with 
KERMIT  commands  and  attributes.  These  help  files  and  KERMIT  User  Guides  can 
be  accessed  through  the  BITNET,  Defense  Data  Network  (DDN)  and  the  mainframe. 
Rather  than  attempt  to  duplicate  them  here,  you  should  access  them  yourself  if  you  are 
in  need  of  further  information.  This  instruction  sheet  will  provide  all  the  information 
you  need  to  access  the  mainframe  and  from  there  you  can  learn  more. 

1.  Versions  of  KERMIT 

There  are  more  than  200  versions  of  KERMIT  circulating  around  for  over  50 
specific  machines  and  more  than  5  for  MS-DOS  in  general.  This  instruction  set  is  writ- 
ten for  KERMIT  version  2.27  which  is  available  from  the  computer  department  with 
several  special  changes  set  up  to  communicate  with  the  mainframe  using  a  Z- 100/ 89. 

2.  Required  Files 

You  will  need  both  MSZ100.EXE  and  MEKERMIT.INI  on  your  disk  to  use 
these  procedures.  The  original  disk  for  this  instruction  sheet  includes  KERMIT.DOC 
and  READ. ME. 

B.  BRIEF  OVERVIEW  OF  PROCEDURES 

1.  Dial  into  the  Mainframe  accessing  SIM 3278. 

2.  Choose  the  VT100-in-the-VT52-mode  terminal  emulator  package. 

3.  Set  up  your  Z- 100/89  in  the  alternate  keypad  mode. 

4.  Log  on  exactly  as  you  would  from  a  terminal  at  school. 

5.  Decide  whether  to  transfer  files  or  do  screen  editing. 

6.  Use  substitute  keys  to  imitate  the  PF  keys. 
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1.     The  Details 

a.     Loading  KERMIT for  MS-DOS 

NOTE:   For  this  instruction  sheet  "<CR>"  means  carrage  return  key, 
<esc>      means    escape    key    and      <ctrl>      means    control    key.  Under    most 

circumstsnces   you  will  use  the  <ctrl>  key   simultaneously  with  another  key. 

Put  the  disk  containing  KERMIT  in  the  active  drive  and  enter: 


MSZ100    <  CR>  This  loads  KERMIT  and  the   system 

will  respond  with  with: 

Heath-Zenith  Z-100  Kermit-MS  V2.27 
Type  ?  for  help 

KERMIT-MS  > 


When  the  prompt  appears  enter: 


DO  IBM  <  CR  >  This  will  set  up  the  communications 

protocall  to  the  correct  values  and 
return  the  prompt,  KERMIT-MS >  . 


b.     Set  Up  Modem 


Now  turn  your  modem  on  and  enter: 


Connect  or  C  <  CR  >  This  begins  the  connect  sequence. 


104 


Next  "dial"  the  mainframe.  For  an  auto-dial  modem  enter: 


ATD6462709    <  CR  >     This  will  call-up  the  computer  for 

1200  or  300  baud  operation. 


NOTE:   If  you  do  not  have  an  auto-dial  modem  follow  your  modem's 
instructions  for  call  or  dial-up. 

The  system  will  respond  with: 

CONNECT  1200 

VM/370  ONLINE-         -PRESS  BREAK  KEY  TO  BEGIN  SESSION 

!   Enter    <CR> 


The  system  will  respond  with: 

Enter  one  of  the  following  commands: 

LOGON  userid  (Example:   LOGON  VMUSER1) 

DIALuserid  (Example:    DIAL  VMUSER2) 

MSG  userid  message      (Example:   MSG  VMUSER2  GOOD  MORNING) 

LOGOFF 

This  is  the  mainframe  dot  prompt. 

DO  NOT  GO  FURTHER  UNTIL  YOU  READ  THE  NEXT  SECTION 
DO  NOT  GO  FURTHER  UNTIL  YOU  READ  THE  NEXT  SECTION 
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c.     What  do  you  want  to  do  this  session  ? 

At  this  point  you  must  make  a  decision  about  what  you  want  to  do.  If  you 
wish  to  transfer  files,  see  TRANSFERRING  FILES,  if  you  wish  to  do  full  screen  editing 
(same  as  being  on  a  terminal  at  school)  continue  with  the  section,  SCREEN  WORK. 

(1)  Screen  work.  You  have  dialed  up  the  iMainframe  and  must  now  get 
to  the  period  prompt.    DON'T  log  on  with  your  user  id  yet.   Instead  enter  the  following: 


DIAL  SIi\13278  <  CR  >    This  will  connect  you  to  the 

mainframe's  communications 
protocall  software. 

The  system  will  respond  with: 

DIALED  TO  SIM3278     091  S  I  M  3  2  7  8    (C)  Simware  Inc.    1984  VERSION  3.4 
Please  Enter  Your  Terminal  ID;  '?'  for  menu,  'L'  for  LOGOFF 


When  asked  what  type  of  terminal  you  are,  enter: 

9    <  CR>  You  may  look  at  the  menu  if  you 

want  by  entering  ?   You  enter  9  to 
choose  the  DEC  VT100  in  the  VT52 
mode,  and  press  RETURN. 

The  screen  will  clear  and  the  large  NPS  logo  will  appear  like  the  one  on  the  3270  con- 
sole's at  school. 


Now  you  must  enter  a  sequence  which  will  turn  your  keypad  on  and  place  your  Z-100 
keypad  in  the  Alternate  character  mode.  Enter: 

<  esc  >  x7  <  CR  >  Note  the  small  (lower  case)  x. 

Place  the  H-89  in  the  shifted 
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keypad  mode  by  pressing  <  ESC>  x6. 
(Note  the  lower  case  x.) 


=  >  The  Z-100  has  separate  arrow  keys  on  the  keypad.    Use 
these  to  move  the  cursor  around. 

=  >  On  the  H-89,  the  shifted  keypad  mode  allows  the  arrow 
keys  to  work  as  is.   To  access  the  rest  of  the  functions, 
you  must  press  the  shift  key  with  the  keypad  key. 


The  system  will  respond  with: 

Enter  one  of  the  following  commands: 

LOGON  userid  (Example:    LOGON  VMUSER1) 

DIAL  userid  (Example:   DIAL  VMUSER2) 

MSG  userid  message      (Example:   MSG  VMUSER2  GOOD  MORNING) 

LOGOFF 

This  is  the  mainframe  dot  prompt. 

Logon  as  you  would  normally  do  at  a  terminal  by  entering: 

logon  XXXXP  <  CR  >     Where  XXXX  is  your  user  Number. 

Your  password  WILL  show  up  on  the 
srceen,  but  no  matter.   This  should 
also  execute  your  exec  files  as 
normal  after  logon.    If  not  press 
return  again. 

The  system  will  respond  with  the  LOGON  message  and  leave  you  with  the  system 
prompt  "dot". 
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There  is  an  attachment  to  this  instruction  which  shows  the  key  equivalents  for  the  Z-100. 
In  all  cases  you  must  enter  the  keys  (in  sequence  if  more  than  one)  and  end  with  a  car- 
riage return  <  CR>  . 

(2)  Transferring  files.  To  transfer  files  you  must  "set  the  mainframe  up" 
to  send  or  receive  a  file  first  .  Then  "drop"  down  to  your  KERMIT  and  do  the  trans- 
ferring. To  drop  down,  you  must  enter  control,  right  bracket,  <  ctrl>  ",  simultaneously, 
and  then  enter  the  appropriate  send  or  receive  on  your  KERMIT. 


Logon  as  you  would  normally  do  at  a  terminal  by  entering: 

logon  XXXXP  <  CR  >     Where  XXXX  is  your  user  Number. 

Your  password  WILL  show  up  on  the 
srceen,  but  no  matter.   This  should 
also  execute  your  exec  files  as 
normal  after  logon.    If  not  press 
return  again. 

The  system  will  respond  with  the  LOGON  message  and  leave  you  with  the  system 
prompt  "dot". 


Now  link  to  the  mainframe's  KERMIT  by  entering: 

Linkto  KERMIT  <  CR  >  The  system  will  respond  with: 

Linked  to  user  kermit  disk  191... 
and  will  give  you  the   KERM IT-CMS  > 
prompt.   There  is  no  help  file 
available,  but  ?  displays  the 
KERMIT  options  available.   This  may 
again  execute  your  exec  files. 
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If  you  have  forgotten  which  file  you  wanted  to  send  or  just  want  to  look,  you  can  see 
your  filelist  (directory)  by  entering  the  following  sequence: 

QUIT  or  Q  <  CR>  Quits  kermit  and  returns  to  cms  at 

which  time  you  can  enter: 

listfile  <  CR>    Which  will  display  your  directory. 

to  get  back  to  kermit  enter: 

KERMIT  <  CR  >         The  system  will  display  KERMIT-CMS. 

To  send  a  file  from  the  main  frame  to  home  computer  enter: 

send  filename  file  type  flemode  <  CR  > 


<  Ctrl  >  -]  <CR>      Drops  to  your  KERMIT-MS>  prompt. 


receive  filename. extension  <CR>        ? 


At  this  time  you  will  see  a  file  transfer  status  menu.  This  will  give  you  a  menu  which 
shows  how  the  transfer  is  working. When  the  transfer  is  complete  it  will  tell  you  (along 
with  some  other        ?   facts  about  that  file  ? 


d.     Logging  off 

You  logoff  at  the  end  of  your  session  as  normal  and  then  enter: 
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<  Ctrl  >  -C]  <  CR  >         The  control,  <  Ctrl  >  ,  and  right 

bracket  "  must  be  done  at  the  same 
time  (simultameously)  and  then  the 
C  and  <CR>. 

Now  you  are  at  the  KERMIT-MS>  prompt.   Enter: 

QUIT  or  Q  <  CR  >    This  will  bring  you  back  to  the 

operating  system. 

2.  Tips  for  300  baud  users 

Since  300  baud  can  be  very  slow,  try  to  minimize  those  actions  which  call  for  a 
complete  screen  update.    Some  examples: 

1.  In  XEDIT,  do  most  of  your  corrections  on  the  whole  page  (using  the  arrow  keys) 
before  you  move  Up  or  Down.   Then  move  a  whole  page  if  possible. 

2.  In  the  Input  mode  in  XEDIT,  use  the  NEWLINE  function  (ESC  <cr> )  to  move 
the  cursor  down  to  column  one  of  the  next  line  instead  of  pressing  <cr>  alone. 
RETURN  <  cr>  causes  the  whole  screen  to  be  updated  as  the  lines  you've  entered 
so  far,  are  moved  up  above  the  action.  Once  you  have  entered  seven  or  so  lines, 
then  press  <  cr>  to  accept  the  lines  and  update  the  screen. 

3.  Z-100/IBM  3270  keyboard  equivalence 

Use  Figure  11  to  imitate  the  various  function  keys  normally  found  on  the  3270 
terminals  connected  to  the  IBM  at  NTS. 
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HOME/SCHOOL  KEY  EQUIVALENCES 

Here 

are  some 

key  equivalences: 

VT- 

■52  (term 

9) 

IBM  3270 

CODES 

H89  (KP=Keypad) 

Z-100 

KEYS 

SENT 

REMARKS 

ARROW  KEYS   <==== 



; > 

<-- 

<-- 

<-- 

<ESC> 

D 

shift  6 

shift  6 

shift  6 

<ESC> 

A 

V 

V 

V 

<ESC> 

B 

--> 

--> 

FUNCTION 

--> 

<ESC> 

C 

> 

KEYS  <' """ 

BLUE<cr> 

F6<cr> 

PF1 

<ESC> 

P 

RED<cr> 

F7<cr> 

PF2 

<ESC> 

Q 

WHITE<cr> 

F8<cr> 

PF3 

<ESC> 

R 

Fl<cr> 

Fl<cr> 

PF4 

<ESC> 

S 

shft  KP 

7<cr> 

KP  7<cr> 

PF5 

<ESC> 

? 

w 

shft  KP 

8<cr> 

KP  8<cr> 

PF6 

<ESC> 

? 

X 

shft  KP 

9<cr> 

KP  9<cr> 

PF7 

<ESC> 

? 

y 

ESC  ?  ra 

<cr> 

KP  -<cr> 

PF8 

<ESC> 

7 

m 

shft  KP 

4<cr> 

KP  4<cr> 

PF9 

<ESC> 

7 

t 

shft  KP 

5<cr> 

KP  5<cr> 

PF10 

<ESC> 

7 

u 

shft  KP 

6<cr> 

KP  6<cr> 

PF11 

<ESC> 

7 

V 

7 

? 

PF12 

? 

shft  KP 

l<cr> 

KP  l<cr> 

PA1 

<ESC> 

? 

q 

Goes  to  CP 

shft  KP 

2<cr> 

KP  2<cr> 

PA2 

<ESC> 

7 

r 

? 

shft  KP 

3<cr> 

KP  3<cr> 

//GOTO(SIM) 

<ESC> 

? 

s 

1    „ 

ESC<cr> 

ESC<cr> 

Newline 

<ESC> 

3270  <--"  key 

shft  ENTER<cr> 

ENTER<cr> 

Alt  Clear 

<ESC> 

7 

M 

also  PA2 

CTRL  a 

CTRL  a 

Insert 

char 

<CTRL 

a> 

CTRL  b 

CTRL  b 

Delete 

char 

<CTRL 

b> 

once  for  each 

char  to  delete 

Figure  11. 


Z100/IBM  3270  Key  Equivalence:  NOTE:  Some  of  the  function  keys 
have  not  been  located,  If  you  find  errors  or  more  definitions,  let  us 
know. 


4.     The  Quick'N'Dirty  Version 

After  doing  this  several  times  you  will  get  to  the  point  when  you  do  not  need 
all  this  information  to  operate  in  the  KERMIT  environment.  Figure  12  fits  neatly  on 
a  three  by  five  card  which  can  be  tucked  into  the  jacket  of  your  KERMIT  disk. 


Ill 


"  MAINFRAME 'N  KERMIT  " 

MSZ100  <CR> 
DO  IBM  <CR> 
modem  on   Connect  <CR>  ATD6462709 

LOGON  XXXXP  <CR>        DIAL  SIM3278  <CR> 

LINKTO  KERMIT  <CR>       <esc>x7  <CR> 

Q  <CR>,  LISTFILE  <CR>    LOGON  XXXXP  <CR> 

KERMIT  <CR> 

set  mainframe  first!     LOGOFF  <CR> 

LOGOFF  <CR>             <ctrl>-C  <CR>,  QUIT 

Figure  12.      KERMIT  Quick  Reference  (3X5  card)  (for  NPS  only) 
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APPENDIX  F.     TEKTRONIX  TERMINAL  EMULATOR 

The  following  programs  were  developed  on  the  Z-100  using  Z-BASIC  under 
MS-DOS  version  2.  The  programs  used  to  generate  the  pictures  in  Appendix  I  were 
compiled  by  the  Z-BASIC  compiler. 

A.     TEKTRONIX  GRAPHICS  TERMINAL  EMULATION  PROGRAM 


TECKTRONIX  4006  /  4010  GRAPHICS  TERMINAL  EMULATOR 
FOR  THE  Z-100  UNDER  MS-DOS  MODIFIED  FOR  THE  DDN 

ORIGINALLY  SUGGESTED  BY  GLEN  ROBERTS  APRIL  28,  1984 
UNDER  Z-DOS  TO  MAKE  THE  Z-100  COMPUTER  EMULATE  A 
TEKTRONIX  PROTOCOL  GRAPHICS  TERMINAL 
THIS  VERSION  WILL  RUN  UNDER  MS-DOS  2  AND  HIGHER 
MODIFIED  BY  R.  SABO  AND  R.  BISHOP  JAN  1988 


CHARACTER  CONSTANTS 


INITIALIZE  VARIABLES 


1 

2 

3 

4 

5 

6 

7 

8 

9 

10  DEFINT  A-Z:DIM  P!(224):DEF  SEG  =  &HE000 

11 

12 

13 

20  CTRLC=3:  FF=12:  X0N=17:  X0FF=19:  ESC=27:  GS=29: US=31: SPACE=32 

21 

22 

23 

30  FALSE=0:  TRUE=NOT  FALSE: GRMODE=FALSE: HAVLOY=FALSE: A=0 

31 

32 

33 

34 

40   BAUD$="1200":  PARITY$="N":  BITS$=M8M 

41 

42 

43 

44 

50   SCREEN  0,0: KEY  OFF:  CLS 

51 

52 

53 

54 

55 

60  R=0:F0R  J=0  TO  392  STEP  16: FOR  1=0  TO  8: P! (R)=( I+J)*128: 
R=R+1:NEXT  I:  NEXT  J 

61  ' 

62  '  ASSIGN  KEY  INTERRUPTS  TO  THE 

63  '  APPROPRIATE  SUBROUTINES 

64  '  THIS  AREA  IS  WHERE  FURTHER  WORK  CAN  TAKE  PLACE 

65  ' 

70  KEY(l)  ON: ON  KEY(l)  GOSUB  530 
80   KEY(2)  ON: ON  KEY(2)  GOSUB  560 
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THE  FOLLOWING  COMMUNICATION  PROTOCOL  CONSTANTS  MAY  BE 
MODIFIED  AS  NEEDED  FOR  THE  APPLICATION  YOU  ARE  UNDER 


HOME  THE  CURSOR  AND  CLEAR  THE  SCREEN 
TURN  KEY  ASSIGNMENTS  OFF 


INITIALIZE  THE  ARRAY  TO  INDEX  THE  BYTES 

FOR  BIT  IMAGE  PRINTING  (NOT  USED  IN  THIS  VERSION) 


OPEN  SERIAL  COMM  CHANNEL  AS  FILE  #1 
OPEN  SCREEN  OUTPUT  AS  FILE  #2 


90  KEY(3)  ON: ON  KEY(3)  GOSUB  590 
100  KEY(4)  ON: ON  KEY(4)  GOSUB  620 
110  KEY(5)  ON: ON  KEY(5)  GOSUB  740 
120  KEY(6)  ON: ON  KEY(6)  GOSUB  470 
130  KEY(7)  ON:  ON  KEY(7)  GOSUB  760 
140  KEY(8)  ON: ON  KEY(8)  GOSUB  780 

150  KEY(9)  ON: ON  KEY(9)  GOSUB  800 

151  ' 

152  '  PRINT  25th  LINE  AND  TITLE  HEADING  ON  SCREEN 

153  * 

160  GOSUB  620 

170  PRINT  "TEKTRONIX  4006  /  4010  GRAPHICS  TERMINAL  EMULATOR" 
180  PRINT 

190  PRINT  "BAUD   :  ";: SCREEN  ,1:  PRINT  BAUD$; : SCREEN  ,0 
200  PRINT  "     PARITY  :  ";: SCREEN  ,1: PRINT  PARITY?; : SCREEN 
210  PRINT  "     BITS   :  ";:  SCREEN  ,1:  PRINT  BITS$; : SCREEN  ,0 
211 
212 
213 
214 
218 

220  OPEN  "COM1:  "+BAUD$+"J"+PARITY$+","+BITS$  AS  #1 
230  OPEN  "SCRN: "  FOR  OUTPUT  AS  #2 
240  PAUSE=FALSE 
241 
242 
243 
244 
245 
256 

250  IF  L0C(1)=0  THEN  430 
251 
252 
253 
254 
255 
256 

260  IF  (LOC(1)>60)  AND  NOT  PAUSE  THEN  PAUSE=TRUE: PRINT  #l,CHR$(XOFF); 
261 
262 
263 
264 
265 

270  LASTA=A:  A=ASC( INPUT$( 1,#1))  AND  127 
271 
272 
273 
274 

280  IF  A<SPACE  THEN  390 
290  IF  NOT  GRMODE  GOTO  420 

292  *  HANDLE  THE  GRAPHICS  CHAR 

293  '  PUT  HIGH  TWO  BITS  INTO  MODE  VARIABLE 

294  '  THEN  PUT  LOW  FIVE  BITS  INTO  THE  BITS  VARIABLE 
295 

300  MODE=A  32:BITS=A  AND  31 
310  ON  MODE  GOTO  320,340,380 
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THIS  IS  THE  MAIN  EXECUTION  LOOP 
FIRST  CHECK  FOR  CHARACTERS  IN  THE  COMM  BUFFER 
IF  NONE  THEN  JUMP  TO  SEE  IF  SYSTEM  IS  WAITING 
FOR  AN  X-ON  ALSO  CHECK  COMM  BUFFER  TO  SEE  IF  FULL 


HANDLE  HANDSHAKING  IF  COMM  BUFFER  IS  ALMOST  FULL  THEN 
SEND  AN  XOFF  TO  THE  REMOTE  SYSTEM  TO  STOP  DATA 
TRANSMISSION  AND  SET  PAUSE  TO  TRUE  TO  INDICATE  THAT 
THE  REMOTE  SYSTEM  IS  WAITING  FOR  AN  X-ON 


SAVE  THE  LAST  RECIEVED  CHARACTER,  THE  READ  A  NEW  CHARACTER  FROM 

THE  COMM  BUFFER 

(STRIP  THE  8TH  BIT  IF  ANY) 


IF  THE  CHAR  IS  A  CONTROL  CHAR  OR  IF  WE  ARE 
NOT  IN  THE  GRAPHICS  MODE  THEN  JUMP 


311 
312 
313 
314 
315 
316 
317 
318 
320 
330 
331 
332 
333 
334 
335 
336 
337 
338 
340 
350 
360 
370 
371 
372 
373 
374 
375 
376 
380 
381 
382 
383 
384 
385 
386 
387 
390 
391 
392 
393 
394 
400 
401 
402 
403 
404 
407 
408 
409 
410 

411 
412 
413 
414 

415 


FOR  THE  CASE  WHERE  MODE  =01  (HIGH  X  OR  HIGH  Y) 

IF  WE  ALREADY  HAVE  A  LOW  Y  THEN  THIS 
MUST  BE  A  HIGH  X,  ELSE  IT  MUST  BE  A  HIGH  Y. 
SHIFT  IT  FIVE  BITS  SO  THAT  THE  LOW  VALUE 
MAY  BE  ADDED  LATER. 

IF  HAVLOY  THEN  HIX=BITS*32  ELSE  HIY=BITS*32 

GOTO  430 

MODE  =  10  (LOW  X) 

THE  HIGH  AND  LOW  DATA  IS  COMPLETE,  START  DRAWING  THE 
VECTOR  ON  THE  SCREEN.   THIS  IS  DONE  USING  THE  Z-BASIC 
"DRAW"  STATEMENT.  SCALING  IS  5/8  X  AND  7/24  Y 
IF  THE  VECTOR  IS  INVISIBLE  ADD  "B"  TO  BLANK  IT. 

Y=15*(780-(LOY+HIY))  52: X=5*(BITS+HIX)  8 
L$="M"+MID$( STR$(X) ,2)+" , "+MID$( STR$( Y) ,2) 
IF  BLANK  THEN  L$="B"+L$ 
DRAW  L$:  BLANK  =  FALSE: HAVLOY=FALSE:  GOTO  430 

FOR  THE  CASE  WHERE  MODE  =  11  (LOW  Y) 

SAVE  LOW  Y  VALUE  AND  REMMEMBER  THAT  WE  HAVE 
RECEIVED  A  LOW  Y 

LOY=BITS: HAVLOY=TRUE:  GOTO  430 

HANDLE  COTROL  CHARACTERS  HERE 

IF  A  GROUP  SEPARATOR  (GS)  THEN  ENTER  THE 

GRAPHICS  MODE  AND  REMMEMBER  THAT  THE  NEXT  VECTOR 

WILL  BE  INVISIBLE  (YOU  ALWAYS  START  WITH  AN  INVISABLE 

VECTOR  SO  YOU  CAN  POSITION  TO  THE  CORRECT  STARTING  PLACE) 

IF  A=GS  THEN  GRMODE=TRUE:  BLANK=TRUE:  CLS:  GOTO  430 

IF  A  UNIT  SEPERATOR  (US)  THEN 
EXIT  THE  GRAPHICS  MODE 

IF  A=US  THEN  GRMODE=FALSE:  LOCATE  25,1:  GOTO  430 


IF  FORM  FEED  (FF)  AND  THE  LAST  WAS  (ESC),  THEN  CLEAR  SCREEN 
AND  THE  25TH  LINE,  THEN  EXIT  GRAPHICS  MODE 

IF  A=FF  AND  LASTA=ESC  THEN  CLS:  LOCATE  25,1: 

PRINT  SPACE$(80);:GRMODE=FALSE:GOTO  430 
i 

1  THE  CHAR  IS  EITHER  A  NORMAL  CONTROL  CHAR 
1  OR  WE  ARE  NOT  IN  GRAPHICS  MODE 
1  JUST  SEND  IT  TO  THE  SCREEN 
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420 
421 
422 
423 
424 
430 
431 
432 
433 
434 
435 
440 
450 
460 
461 
462 
463 
464 
470 
480 
490 
500 
510 
520 
522 
523 
524 
530 
531 
532 
535 
536 
540 
550 
554 
555 
556 
557 
558 
560 
570 
580 
590 
600 
610 
611 
612 
613 
614 
615 
620 
630 
640 
650 
660 
670 


PRINT  #2,CHR$(A); 

IF  X-OFF  HAS  BEEN  SENT  SEE  IF  BUFFER  IS  ALMOST  EMPTY 
IF  IT  IS,  SEND  AN  X-ON 

IF  (LOC(1)<10)  AND  PAUSE  THEN  PAUSE=FALSE:  PRINT  #l,CHR$(XON); 

NOW  POLL  THE  KEYBOARD.  IF  A  KEY  HAS  BEEN  HIT 
THEN  TRANSMIT  THAT  CHARACTER  TO  THE  REMOTE  SYSTEM 
AND  GO  BACK  TO  THE  TOP  OF  THE  LOOP 

A$=INKEY$ 

IF  A$<>""  THEN  PRINT  #1,A$; 

GOTO  250 
i 

'  SUB  TO  PRINT  SCREEN  USING  BIT  IMAGE  GRAPHICS  ON  C. ITOH  PROWRITER 

'  OTEHR  SIMILAR  PRINTERS, 
i 

BEEP 


RETURN 

i 

1  ROUTINE  TO  NAME  AND  SAVE  SCREEN  PICTURES 
t 

LOCATE  1,1: INPUT" PICTURE  NAME:  ",SCNM$ 
t 

t 

BSAVE  SCNM$, 0,50256! 

GOSUB  620 

BEEP 

RETURN 

THE  SPACES  HERE  CAN  BE  USED  TO  PROGRAM  THE  "FUTURE" 
THINGS  REMOVED  FOR  OUT  PROOF  OF  CONCEPT  VERSION 
WHEN  CALLED  THEY  WILL  JUST  BEEP  FOR  NOW 

BEEP 

BEEP 

RETURN 

BEEP 

BEEP 

RETURN 

SUB -ROUTINE  TO  CLEAR  SCREEN  AND  PRINT  A  REMINDER  PROMPT 
ON  THE  25TH  LINE.   THE  PROMPT  SHOWS  THE  FUNCTION  KEYS 
AND  THEIR  ASSIGNED  STSTUS 


CLS: LOCATE  25,1 

PRINT  "  1";:  SCREEN  ,1:  PRINT  "SAVE 

PRINT  "  2";: SCREEN  ,1:  PRINT  "FUTURE 

PRINT  "  3";:  SCREEN  ,1: PRINT  "FUTURE 

PRINT  "  4";: SCREEN  ,1: PRINT  "CLS 

PRINT  "  5";:  SCREEN  ,1: PRINT  "QUIT 


SCREEN  ,0 
SCREEN  ,0 
SCREEN  ,0 
SCREEN  ,0 
SCREEN  ,0 
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680 

PRINT  " 

6"; 

SCREEN 

,1: 

PRINT 

"FUTURE"; 

SCREEN  ,0 

690 

PRINT  " 

7"; 

SCREEN 

,1: 

PRINT 

"  C    "; 

: SCREEN  ,0 

700 

PRINT  " 

8"; 

SCREEN 

,1: 

PRINT 

"XOFF  "; 

SCREEN  ,0 

710 

PRINT  " 

9"; 

SCREEN 

,1: 

PRINT 

"XON   ": 

SCREEN  ,0 

720  LOCATE  1,1 

730  RETURN 

731  ' 

732  '  CLOSE  ROUTINE 

733  ' 

740  CLOSE: KEY  OFF: CLS 

750  STOP 

751  ' 

752  '  ROUTINES  NEEDED  TO  SEND  CONTROL  CHARS  NORMALLY 

753  '  TRAPPED  IN  ZBASIC  INTEREPRETED  VERSIONS.  MAY  NOT 

754  '  BE  NEEDED  IN  THE  COMPILED  VERSION 

755  ' 

760  PRINT  #1,CHR$(CTRLC); 

770  RETURN 

780  PRINT  #1,CHR$(X0FF); 

790  RETURN 

800  PRINT  #1,CHR$(X0N); 

810  RETURN 


B.     PLAYBACK  PROGRAM  LISTING 

While  this  is  not  very  elegant  it  does  serve  its  purpose.    Further  work  on  this  pro- 
gram could  do  much  to  improve  its  functions. 


'  THIS  IS  THE  LO-CO-GRAF  "PLAY  BACK"  PROGRAM 
'  IT  PROMPTS  FOR  THE  NAME  OF  THE  PICTURE  TO 


t 


1 

2 

3 

4 

5 

6 

10 

20 

30 

31 

33 

34 

35 

36 

40 

50 

60 

70 

71 

72 

90  A$=INKEY$: IF  A$="" 

100  STOP 


GET  FROM  A  FILE  AND  THEN  PAINTS  IT  ON  THE  SCREEN 
AT  THAT  POINT,  YOU  CAN  PRINT  IT  TO  PAPER  WITH  THE 
SCREEN  DUMP  PROGRAM 


CLS 

DEF  SEG=&HE000 
i 

1  LINES  40  THRU  70  GET  THE  NAME  OF  THE  FILE  DATA 

*  TO  BE  DISPLAYED,  PLAY  BACK  THE  PICTURE  AND 

*  RINGS  A  BELL  TO  TELL  YOU  IT  IS  COMPLETE. 

i 

INPUT  "NAME  OF  PICTURE  FILE  TO  LOAD  ";  FILENAME? 

CLS 

BLOAD  FILENAME$,0 

BEEP 

LOCATE  25,1:  PRINT  "ENTER  ANY  KEY  TO  QUIT       OR" 


LOCATE  25,31:  PRINT 


PRESS  SHIFT  F-12  TO  PRINT" 


THEN  90 
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APPENDIX  G.     SCREEN  DUMP  ROUTINE 

This  documentation  file  is  available  on  the  distribution  disk  for  the  screen  dump 
routine  titled: 

SCDMP.COM  -  Version  3.4  -  15-Oct-85 

SCREEN  DUMP  UTILITY  FOR  H/Z-100 

(for  U.  S.  Government  use  only) 


A.     INTRODUCTION 

SCDMP  is  a  utility  that  allows  reproduction  of  a  complete  video  screen  on  a 
dot  matrix  printer,  including  both  text  and  graphics,  without  having  to  exit  the 
current  program.  The  SCDMP  program  may  be  loaded  manually  (by  entering 
SCDMP  <cr>)  or  automatically,  via  'autoexec.bat',  into  memory  at  the  beginning 
of  a  session  where  it  remains  resident  until  needed.  To  print  a  desired  stationary 
screen,  simply  press  <SHIFT-F12>,  which  generates  an  interrupt-5  and  activates 
the  screen  dump. 

The  program  allows  a  choice  of  which  color  bank  of  video  RAM  is  dumped  (if 
the  user  has  all  banks  of  color  RAM  in  hisZlOO).  The  number  of  VRAM  banks 
installed  in  your  computer  is  determined  by  SCDMP  upon  initial  load.  For  the 
color  version,  entering  a  <B>  for  blue,  <R>  for  red,  <G>  for  green,  or  <A> 
for  all  banks  immediately  after  the  <  SHIFT-F12>  will  select  the  VRAM  bank  to  be 
printed.  If  no  character  is  entered,  <A>11  banks  is  the  default.  If  only  one  bank 
of  color  RAM  is  installed,  only  the  green  bank  can  be  dumped. 

The  program  also  allows  multiple  density  printing  for  some  printers.  Entering 
an  <H>  immediately  after  the  <SHIFT-F12>  or  color  selection  would  cause  the 
printer  to  use  a  higher  density  mode  for  printing.  The  default  density  is  normal 
or  standard  density.  The  program  also  allows  a  choice  of  printing  the  twenty-fifth 
line,  if  displayed.  Entering  a  <D>  immediately  after  the  <SHIFT-F12>  or 
color  or  density  selection  will  cause  SCDMP  to  dump  the  25th  line  if  it  is  dis- 
played. 

The  program  also  allows  the  default  values  for  the  switch  settings  to  be 
changed  at  any  time  after  the  program  is  loaded.   Entering  a    <  C  >    after  any  of  the 
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above  settings  will  cause  a  change  in  the  default  values  only.  They  will  be  reset 
as  requested  and  a  beep  will  sound  to  confirm  the  reset.  The  screen  will  not  be 
dumped. 

Approximately  three  seconds  is  allowed  after  initiation  of  SCDMP  before  the 
default  values  are  assumed.  The  default  values  can  also  be  changed  at  the  time  of 
initial  load  of  screen  dump,  by  entering  the  appropriate  changes  via  the  command  line, 
such  as 

SCDMP  xyz<cr> 

where  x  =   <  B  >  lue,  <  R  >  ed,  <  G  >  reen,  or  <  A  >  11  banks  default 
y  =    <  N  >  ormal  or  <  H  >  igh  density  default 
z  =    <  D  >  ump  25th  line,  if  displayed 

This  will  allow  SCDMP  to  be  setup  with  the  proper  defaults  for  your  application. 
Activation  would  not  require  the  switches  after  the  <SHIFT-F12>.  This 
makes  calling   SCDMP  from  within  another  program  more  versatile. 

In  the  event  that  it  is  necessary  to  stop  the  printing  of  a  screen,  entering 
<  ESC  >  during  printing  of  the  screen  will  abort  the  dump  (a  'Q'  can  also  be  used  if 
called  from  within  another  program). 

SCDMP  can  be  activated  from  within  many  popular  programs  such  as  Multiplan, 
ZBASIC,  Graftalk,  ZDS  Business  Graphics,  Z-Chart,  Doodler,  CHART,  and  others. 
SCDMP  will  not  work  with  Lotus  123  or  Watchword  as  these  programs  bypass  the 
MSDOS  'get  character'  call.  SCDMP  conforms  to  the  operational  'standard'  created 
by  Zenith's   PSC.ASM,   except   that  both  graphics  and  text  are  reproduced. 

B.  REQUIREMENTS 

This  program  requires  the  ZDOS/MSDOS  operating  system  (Version  1.25  or 
higher)  on  a  H/Z-100  computer.  The  printers  currently  supported  for  U.  S.  Gov- 
ernment use  are  the  Epson  MX/RX/FX  Series  with  Graftrax,  the  Okidata  Microline 
83A,   and  Zenith/MPI  99/150  Series. 

C.  DISTRIBUTION  FILES 

The  following  files  are  included  on  the  distribution  disks  of  SCDMP.  Documenta- 
tion for  operation  and  modification  of  the  programs  is  also  included. 
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SCDMP    .DOC  Screen  Dump  information 

SCDMPEPS.COM  Version  for  Epson  MX  Series 

SCDMP0K2.COM  Version  for  Okidata  Microline  Series 

CDMPMPI  .COM  Version  for  Zenith/ M  PI  99/150  Series 

SCDMP    .BAT  Batch  file  for  auto  load  of  SCDMP.COM 
(rename  the  appropriate  program  to 
SCDMP.COM) 


D.     INSTALLING  THE  PROGRAM 

Choose  the  version  of  the  screen  dump  required  by  the  specific  printer  ap- 
plication.      Rename    the    version    to  SCDMP.COM     as  follows: 

REN  SCDMPxxx.COM  =  SCDMP.COM 

Load  the  screen  dump  program  into  resident  memory  as  follows: 

SCDMP<cr>    or    SCDMP  xyz<cr> 

A  sign-on  message  will  display  the  version  number  and  the  printer  application 
with  instructions  for  dumping  the  screen.  Screen  dump  instructions  will  be  similar 
to    the  following: 

To  dump  screen,  type:    <  SHIFT-F12>  fflW"fflX"fflY"fflZ" 

fflW  =   <G>reen  or  <B>lue  or  <R>ed  or  <  A>  11  banks" 

fflX  =   <  N  >  ormal  or  <  H  >  igh  density" 

fflY  =   <D>ump  25th  line" 

fiTZ  =   <  C  >  hange  default  settings" 
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defaults:   VRAM  bank  =  A   print  density  =  N 

To  abort  dump  during  printing,  type:     <  ESC  > 

Typing  of  <  SHIFT-F12>  -W—  X— Y--Z-  will  suspend  execution  of  the  current 
program,  dump  the  screen  to  the  printer,  and  return  to  the  current  program  with  no 
change. 

NOTE:    Versions    of    SCDMP  are  available    for 
other  printers.   Contact  Mr.     Les    Bordelon    at 
(714)   793-S853   for  additional  information. 

Program  Author: 
Leslie  L.  Bordelon 
1453  Femwood  Drive 
Redlands,  CA  92374 
714-793-8853 


Additional  Credits  to: 

Digital  Information  Systems  (Original  Graphics  Routines) 
Zenith  Data  Systems  (Interrupt-5  Handling  from  PSC.COM) 


121 


APPENDIX  H.     ACCESSING  THE  BRIEFING  AID  SYSTEM 

This  file  is  on  the  DDN  viewer  system  for  accessing  the  Briefing  Aid  System. 
It  explains  how  to  configure  the  information  file  which  must  be  placed  in  your  DDN 
directory.   The  file  is  titled: 

<  LEVEL2>  USING-TAC-TERMINALS.DOC. 3 

Using  a  Graphics  Terminal  on  the  TAC 
Revised  27-Sep-83 

Before  attempting  to  use  a  Graphics  Terminal  on  a  TAC,  verify  that  port  to 
be  used  is  set  in  "Wild  Mode"  and  "Quiet  Mode".  These  settings  must  be  authorized 
by  the  site  liaison  and  executed  by  the  Network  Operations  Center.  Only  if  "Wild 
Mode"  is  enabled  will  the  Graphics  System  be  able  to  connect  to  the  TAC;  if  not 
enabled,  the  Graphics  System  will  simply  minute  during  Initialization  and  then  return 
an  error  (subcode  =  64009). 

"Quiet  Mode"  suppresses  all  messages  on  the  TAC  port.  This  means  no  "TCP 
Trying...",  "Open",  or  "Closed"  messages  should  appear  when  attempting  to  use  the 
Graphics  Terminal  as  a  regular  terminal. 

Once  you  have  determined  that  the  port  is  correctly  tailored,  issue  the  fol- 
lowing commands  to  the  TAC   from  your  Graphics  Terminal: 

@  RESET  <  return  > 

(Theage  similar  to:) 

@ PROTOCOL  TCP  <  return  > 

(This  command  should  no  longer  be  required) 

@ECHO  HALFDUPLEX 

(Instructs  the  TAC  not  to  echo  characters) 
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Use  another  terminal  to  login  and  run  your  program  using  the  string 
"DEVICE  =  (T,RAND-TAC-xxx)"  in  the  INIT  command,  "xxx"  should  be  the  TCP 
port  number,  in  octal,  of  the  graphics  terminal  on  the  TAC.  TCP  port  numbers  may 
be  calculated  from  the  terminal  port  number  in  the  herald  after  the  RESET  command 
(in  the   above  case,  the  terminnumber  is  3). 


Terminal 

Pc 

>rt 

Number 

TCP 

Port  Number  (Octal) 

1 

427 

2 

1027 

3 

1427 

4 

2027 

5 

2427 

6 

3027 

p  256  *  p  +  23 

(expressed   in  octal) 

For  example,  to  run  your  program  on  a  Tektronix  connected  to  terminal  port  4  on 
CCA-TAC  use  the  initialization  string: 

BACKEND  =  (TEKTRONIX).DEVICE  =  (T,CCA-TAC-2027) 


When   you're  done  using  the  Graphics  Terminal,    you  may  have  reset  Echoing  on 
the  TAC  porCHO  REMOTE 
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APPENDIX  I.     SAMPLE  MAPS  GENERATED  BY  LO-CO-GRAF  AND 

THE  BRIEFING  AID  SYSTEM 

The  following  cartographic  products  were  displayed  by  the  LO-CO-GRAF  terminal 
emulation  system  using  the  Briefing  Aid  System  for  map  generation.  The  maps  were 
transferred  from  USC-ISI  via  DDN  to  a  Z-100  microcomputer  and  then  printed  on  an 
Epson-equivalent  dot  matrix  printer  using  a  screen  dump  routine.  Examples  of  maps 
and  charts  printed  under  these  options  are  listed  in  Table  3. 

Table  3.     GUIDE  TO  LO-CO-GRAF  MAPS 


Map  Title 

Page 

Airroutes.GPX 

37 

North-West  Europe 

38 

Atlantic  Ocean  and  Caribbean  Sea 

125 

Mediterranean  Sea 

126 

Tyrrhenian  Sea 

127 

North  Sea 

128 

English  Channel  with  political  boundaries 

129 

Straits  of  Hormuz 

130 

Ethiopian  Conflict 

131 
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Figure  13.      Atlantic  Ocean/ Caribbean  Sea  (solid  landfill) 
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Figure  14.      Mediterranean  Sea  (solid  landfill) 
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Figure  15..    Tyrrhenian  Sea  (solid  landfill) 
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Figure  16.      North  Sea  (solid  landfill) 
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Figure   17.      English  Channel  (political  boundaries) 
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XopMySOB     ripOJlMB 


■f 


Figure  18.      Straits  of  Hormuz  (Russian  version) 
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BUDAN 


Figure   19.      Ethiopian  Conflict  (tactical  map) 
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APPENDIX  J.     SAMPLE  MAPS  GENERATED  BY  DISSPLA 

The  generated  maps  for  the  major  systems  described  in  this  thesis  follow.  The  dif- 
ferences in  line  thickness  is  a  function  of  the  printer  being  used  and  does  not  reflect  on 
the  cartographic  resolution.  These  maps  were  generated  by  DISSPLA  version  10.2 
World  Coast  Utilities  Option  and  printed  by  an  IBM  3800  laser  printer.  Examples  of 
maps  and  charts  printed  under  these  options  are  listed  in  Table  4. 

Table  4.     GUIDE  TO  DISSPLA  GENERATED  MAPS 


Map  Title 

Page 

Washington,  DC 

18 

North- West  Europe 

39 

World  Mercator  Projection 

133 

Cape  Canaveral;  Kennedy  Space  Center 

134 

Carribean  Operating  Area 

135 

Mediterranean  Operating  Area 

136 

Japan  and  the  Kurile  Islands 

137 

Northern  Flank  of  NATO 

138 

North  and  South  America 

139 
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THE  WORLD 

90°  N 


90"  S 


DISSPLA  MAP 


Figure  20.      World  Map 
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Figure  21.      Cape  Canaveral/Kennedy  Space  Center  Area 
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Figure  22.      Caribbean  Sea 
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Figure  23.      Mediterranean  Sea 
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Figure  24.      Japan  and  the  Kurile  Islands 
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Figure  25.      Northern  Flank  of  NATO 
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Figure  26.      North  and  South  America 
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